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ABSTRACT 

"  ...the  future  of  systems  engineering  can  be  said  to  be  model-based"  according  to  the  International 
Council  on  Systems  Engineering  (INCOSE)  vision  for  2020.  Within  Australia,  Model-Based 
Systems  Engineering  (MBSE)  is  emerging  on  a  greater  number  of  projects  and  across  a  broader 
range  of  organisations. 

The  2012  MBSE  Symposium  explored  the  innovative  application  of  MBSE  methodologies  to 
Concept  Engineering.  Concept  Engineering  can  be  described  as  the  application  of  systems 
engineering  principles,  processes,  methods,  techniques  and  tools  to  the  identification  and  analysis 
of  the  needs  of  capability  users  and  other  stakeholders. 

The  symposium  included  two  keynote  presentations  and  fifteen  presentations  from  DSTO, 
industry  and  academia.  It  also  included  two  workshop  sessions  that  explored  the  use  of  capability 
system  models  as  part  of  the  contracting  process. 
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1.  Introduction 
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1.1  Overview 

". .  .the future  of  systems  engineering  can  be  said  to  be  model-based"  according  to  the  International 
Council  on  Systems  Engineering  (INCOSE)  vision  for  2020. 

Within  Australia,  Model-Based  Systems  Engineering  (MBSE)  is  starting  to  emerge  on  a  greater 
number  of  projects  and  across  a  broader  range  of  organisations.  This  suggests  that  there  is  a 
greater  appreciation  of  the  benefits  that  MBSE  affords  a  project.  An  informal  symposium  on 
MBSE  in  20111  was  so  successful  that  DSTO  again  organised  an  MBSE  Symposium  in  2012.  As 
a  result  of  feedback  from  participants,  the  organising  committee  retained  a  similar  format  for 
the  2012  Symposium,  involving  a  single  stream  of  presentations,  even  though  this  limited  the 
number  of  papers  that  could  be  presented. 

The  MBSE  Symposium  held  at  DSTO  Edinburgh,  South  Australia  on  27-28  November  2012, 
explored  the  innovative  application  of  MBSE  methodologies  to  Concept  Engineering.  Concept 
Engineering  can  be  described  as  the  application  of  systems  engineering  principles,  processes, 
methods,  techniques  and  tools  to  the  identification  and  analysis  of  the  needs  of  capability 
users  and  other  stakeholders. 

The  2012  MBSE  Symposium  was  attended  by  88  Australian  and  international  participants,  and 
was  streamed  live  from  Edinburgh  to  DSTO  sites  in  Melbourne  and  Canberra.  It  included  two 
keynote  presentations  and  fifteen  presentations  from  DSTO,  industry  and  academia  on  a  wide 
range  of  MBSE  topics  related  to  Concept  Engineering.  The  symposium  also  included  two 
workshops  that  explored  the  use  of  capability  system  models  as  part  of  the  contracting 
process. 

The  organising  committee  thanks  the  Defence  Systems  Innovation  Centre  (DSIC)  for  their 
generous  sponsorship,  and  INCOSE,  the  Systems  Engineering  Society  of  Australia  (SESA)  and 
the  DSTO  Simulation  Hub  for  their  support. 

1.2  Symposium  Contacts 


Conference  Chair 

Kevin  Robinson  (DSTO) 

Technical  Chair 

Quoc  Do  (UNISA) 

Technical  Reviewers 

Ase  Jakobsson  (DSTO),  Despina  Tramoundanis  (DSTO)  and  Jon  Hallett 
(Deep  Blue  Tech) 

Technical  Program 
Coordinator 

Wayne  Power  (DSTO) 

Secretary  (General) 
Secretary  (Finance) 

Wayne  Power  (DSTO)  and  Brendan  Kirby  (DSTO) 

Wendy  Butler  (DSTO) 

Symposium  Editor 

Michele  Knight  (DSTO) 

Social  Coordinator 

Allison  Lang  (Aerospace  Concepts) 

Administration 

Rebecca  Rocca,  Charmae  Bell 

1  Rian  Armstrong,  Editor  (2012)  Symposium  on  Model-Based  Systems  Engineering  Proceedings , 

Held  24th  -  25th  October  2011,  DSTO  Edinburgh ,  DSTO-GD-0698 
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1.3  2012  MBSE  Symposium  Program 


Tuesday  27  November  2012 


Time  _ 

,  t  Event  or  Presentation  Title  Presenter 

(ADL) 

Facilitator 

8:30  Registrations  open 

9:00  Welcome  &  admin  Kevin  Robinson 

SESA  Welcome  Mike  Ryan 

Kevin  Robinson 

9:30  Keynote:  How  to  eat  an  elephant  -  building  a  constituency  for  Andrew  Parfitt, 

research  in  simulation  and  modelling  University  of  South  Australia 

10:00  Faster,  Better,  Cheaper  -  The  Fallacy  of  MBSE?  David  Long 

10:30  Refreshments 

11:00  Lessons  Learned  in  Introducing  MBSE  -  Post  2009  Peter  Campbell 

David  Harvey 

11:30  Theatre  of  Operations:  An  Entertaining  Problem  Tommie  Liddy,  Michael  Waite, 

Paul  Logan,  David  Harvey 

12:00  Lunch 

12:45  Using  MBSE  to  Understand  the  Link  between  Capability  Acquisition  Simon  Demediuk,  Wayne  Power, 

Projects  and  DSTO  Technology  Advice  Brett  Morris 

Jon  Hallett 

13:15  Enhancing  the  Clarity  of  Low  Level  Decisions  on  the  Goals  of  Large  Robert  Dow,  Lyn  Dow,  Kim  Baddams, 

Complex  Projects  David  Kershaw 

13:45  Employing  Concept  Definition  Techniques  to  Deliver  Value  on  the  RAN  Steven  J.  Saunders 

Air  Warfare  Destroyer  Program 

14:15  Refreshments 

14:45  Workshop  1:  What  is  a  'Capability  System  Model'? 

Workshop  2:  MBSE  Practices  Across  the  Contractual  Boundary 

WS  1:  Mike  Ryan 

WS  2:  Quoc  Do,  Jonathan  Hallett 

16:15  Workshop  summary  presentations  and  discussion 

17:00  Close  Day  1 

19:00  Symposium  Dinner  -  Crowne  Plaza 

Wednesday  28  November  2012 


Time 

Event  or  Presentation  Title 

Presenter 

Facilitator 

8:30 

Morning  coffee/tea 

9:00 

Keynote:  Rebuilding  the  Tower  of  Babel:  Better  Communications  with 
Standards 

Matthew  Hause, 

Object  Management  Group 

9:30 

A  Proposed  Pattern  of  Enterprise  Architecture 

Dr  Clive  Boughton 

Quoc  Do 

10:00 

Incorporating  MBSE  into  SoS  Engineering  Practice 

Pin  Chen,  Mark  Unewisse 

10:30 

Refreshments 

11:00 

Model  Based  Systems  Engineering  -  Issues  of  application  to  Soft 
Systems 

Ady  James,  Alan  Smith,  Michael  Ernes 

11:30 

The  Best  of  Both  Worlds  -  CORE-based  WSAF  with  DOORS-based 
Requirements  Management 

Roger  McCowan,  Michael  Waite 

Stephen  Cook 

12:00 

A  Formal  Modelling  Language  Extending  SysML  for  Simulation  of 
Continuous  and  Discrete  Systems. 

Mark  Hodson  and  Nick  Luckman 

12:30 

Lunch 

13:15 

Towards  the  Use  of  Network  Analysis  Method  In  Analysing  Node 
Properties  In  a  System  Model 

Li  Jiang,  Hossein  Seif  Zadeh 

Ase  Jakobsson, 
Kevin  Robinson 

13:45 

Streaming  transition  (switch  between  sites) 

13:50 

Technical  Risk  Analysis  -  Exploiting  the  Power  of  MBSE 

Despina  Tramoundanis,  Wayne  Power, 
Daniel  Spencer 

14:20 

Refreshments 

14:45 

Modelling  the  Management  of  Systems  Engineering  Projects 

Daniel  Spencer,  Shaun  Wilson 

Despina 

15:15 

Potential  Benefits  of  Product  Lifecycle  Management  (PLM)  2.0  Social 
Networking  Capabilities  within  MBSE 

Axel  Reichwein,  Shaunak  Hemant  Shroff 

Tramoundanis 

15:45 

Closing  remarks 

Kevin  Robinson 

16:00 

Close  Day  2 
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2.  KEYNOTE  1:  How  to  eat  an  elephant  -  building  a 
constituency  for  research  in  simulation  and  modelling 


Professor  Andrew  Parfitt 

Pro  Vice  Chancellor  and  Vice  President,  Division  of  Information  Technology, 
Engineering  and  the  Environment,  University  of  South  Australia 

Abstract 

Research  to  develop  disciplines  and  capabilities  that  underpin  outcomes  for  a  variety  of 
applications  often  struggles  to  gain  support  from  end  users,  partly  due  to  assumptions  made 
about  the  utility  of  the  underpinning  science  or  technologies  and  partly  because  it  is  difficult 
to  find  a  constituency  within  some  application  domains  to  champion  the  adoption  of  new 
techniques.  Modelling  and  simulation  and  systems  engineering  are  broad  areas  that  seems  to 
fall  within  this  category  outside  a  few  recognised  communities. 

This  presentation  discusses  some  of  the  ways  in  which  the  research  community  might  look  to 
engage  users  in  order  to  develop  an  understanding  of  the  benefits  associated  with  the 
adoption  of  a  systems  approach,  and  in  particular  the  use  of  modelling  and  simulation  in  the 
design,  implementation  and  operations  phases  of  large  projects. 

Presenter  Biography 

Professor  Andrew  Parfitt  commenced  as  Pro  Vice  Chancellor  and  Vice  President  of  the 
Division  of  Information  Technology,  Engineering  and  the  Environment  in  August  2007. 
Previously,  he  was  the  Director  of  UniSA's  Institute  for  Telecommunications  Research  (ITR) 
(2004  -  2007),  one  of  Australia's  foremost  ICT  research  organisations. 

In  2006  he  concurrently  acted  as  Head  of  the  School  of  Electrical  and  Information  Engineering 
and  led  the  strategic  planning  that  resulted  in  the  formation  of  the  new  Defence  and  Systems 
Institute  (DASI)  and  a  closer  cooperation  between  our  electrical  and  electronic  engineering 
related  disciplines. 

Andrew  has  been  a  major  contributor  to  the  ATN  Universities'  push  to  establish  and  maintain 
measures  of  applied  research  on  the  research  evaluation  agenda. 

He  has  a  PhD  in  Electrical  and  Electronic  Engineering  from  Adelaide  University  and  was  an 
Associate  Dean  in  the  Faculty  of  Engineering  there,  before  joining  CSIRO's 
Telecommunications  and  Industrial  Physics  division  in  Sydney  in  1998.  Within  the  CSIRO  he 
led  the  Space  and  Satellite  Communication  Systems  team  from  2001.  During  this  time  he  was 
responsible  for  fundamental  and  applied  research  in  areas  ranging  from  radar  and 
communications  to  satellite  systems  and  radio  astronomy  technologies. 

Andrew  has  had  an  outstanding  career  as  a  specialist  in  antenna  and  radio  systems  and  more 
recently  in  areas  relating  to  space  science  and  technology.  A  graduate  in  engineering  from  the 
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University  of  Adelaide,  he  began  his  professional  career  with  the  Defence  Science  and 
Technology  Organisation  before  returning  to  study  under  a  DSTO  cadetship. 

In  2003  Andrew  became  CEO  of  the  Cooperative  Research  Centre  for  Satellite  Systems 
(CRCSS),  the  national  research  group  responsible  for  launching  FedSat,  Australias  first 
satellite  in  30  years. 

He  has  held  adjunct  academic  positions  at  UniSA,  the  University  of  Adelaide,  the  University 
of  Sydney  and  Macquarie  University.  In  a  professional  capacity  he  is  a  Senior  Member  of  the 
Institute  of  Electrical  and  Electronics  Engineers  and  has  been  Chair  of  both  its  South  Australia 
and  New  South  Wales  Sections.  He  is  Chair  of  the  Australian  Academy  of  Science  National 
Committee  for  Radio  Science,  and  is  a  Fellow  of  Engineers  Australia. 

He  is  a  Board  Member  of  the  Defence  Teaming  Centre  and  the  Technology  Industry 
Association. 

In  2010  he  was  appointed  to  the  Commonwealth  Government's  Space  Industry  Innovation 
Council. 

Presentation 


© 

UniSA 

How  to  Eat  an  Elephant: 
Building  a  Constituency  for  Research  in 
Simulation  and  Modelling 

Professor  Andrew  Parfitt 
Pro  Vice  Chancellor  and  Vice  President 
Division  of  IT,  Engineering  and  the  Environment 
The  University  of  South  Australia 
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UniSA 


The  University  of  South  Australia 


37,000  students  (undergraduate,  postgraduate, 
research) 


UniSA 


’  N 


6,000  International  onshore  students 
3,500  staff  (academic,  research,  professional) 

4  Academic  Divisions,  4  City  Campuses 

Business;  Health  Sciences;  Education  Arts  and 
Social  Sciences;  IT  Engineering  and  Environment 

A$550m  budget,  A$60m  research  income 
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The  Problem  of  Enabling  Disciplines: 

What  is  an  enabling  discipline? 
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The  Problem  of  Enabling  Disciplines: 

How  do  you  build  an  enabling  discipline? 


UniSA 


\ 

■jtC 


Challenges 


1.  Identity  -  what  is  it? 

2.  Utility  -  what  does  it  do? 

3.  Maturity  -  does  it  work? 

4.  Ubiquity  -  doesn’t  everyone  do  it? 


Classic  Example  -  Statistics 
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•  Education  -  skills,  professions,  CPD ... 

•  Research  -  knowledge  creation,  innovation  ... 

•  Engagement - 

•  Partnerships  and  collaboration 

•  Industry  alliance  programs 

•  Networks  and  clusters 

•  Technology  transfer 


i 


Alignment  of  Interests 


Materials  Science  and  Technology 

•  High  quality  research  (ERA  4  and  5) 

•  Collaborative  program  (CRCs,  ITCs,  CoEs) 


Example  partnership: 

•  SMR  Automotive  -  plastic  mirrors 

•  Long  term  strategic  alliance 

•  Staff  exchanges,  joint  appointments 
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Model  2:  Industry  Alliance  Program 


ICT  Industry  -  Sector  Wide 
Emphasis  on  developing  work-ready  skills 
Innovation  factory  -  bite  size  real  problems 
Partnership  on  student  projects 
Workplace  experience  -  building  familiarity 
Promotion  of  outcomes 


GS)  Model  3:  Research  and  Innovation 
umsA  Clusters 


•  Strategic  Research  Partnerships 

•  Multidisciplinary  challenges 

•  Extensive  consultation  and  mapping 

•  Wide  participation  across  UniSA 

•  Innovative  initiatives 

•  Zero  Waste  SA  Centre 

•  Northern  Business  Research  Partnerships 

•  From  seed  funding  to  major  coinvestment 
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Model  4:  Technology  Transfer 

UniSA 


•  ITEK 


•  Technology  transfer  nodes 

•  Spin  out  companies 

•  Joint  ventures 

•  IP  licencing 

•  Incubation 


UniSA 


Key  Success  Attributes 


Communication  and  openness 
Realistic  expectations 
Clarity  around  purpose  and  outcomes 
-it  •  Understanding  of  opportunities 

iynn  pi 

n* ll  •  Leveraging  successful  models 
Handling  Intellectual  Property 
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3.  Faster,  Better,  Cheaper  -  The  Fallacy  of  MBSE? 


David  Long 
Vitech  Corporation 


Abstract 

Scope,  time,  and  cost  -  the  three  fundamental  constraints  of  a  project.  Project  management 
theory  holds  that  these  three  dimensions  are  inextricably  linked  as  competing  constraints.  To 
complete  a  project  faster  must  sacrifice  budget  or  scope  (whether  explicitly  through  reduced 
capability  or  implicitly  through  lower  quality).  Likewise,  to  complete  a  project  at  lower  cost 
inevitably  results  in  longer  schedules  or  reduced  capability/ lower  quality.  As  the  standard 
saying  goes  today,  "faster,  better,  cheaper  -  pick  any  two". 

When  Daniel  Goldin  became  Administrator  of  the  US  National  Aeronautics  and  Space 
Administration  (NASA),  he  championed  the  cause  of  a  unified  "faster,  better,  cheaper" 
mentality.  Using  this  management  mantra,  Goldin  sought  to  save  money  while 
simultaneously  improving  performance  and  accelerating  schedule.  In  other  words,  he  sought 
to  deliver  results  seemingly  impossible  given  the  "iron  triangle"  of  project  management.  After 
multiple  mission  failures  including  the  twin  Mars  mission  disasters  in  1999,  the  concept  of 
faster-better-cheaper  was  widely  derided,  and  we  once  again  returned  to  the  model  of  "pick 
any  two". 

Today,  with  the  rise  of  Model-Based  Systems  Engineering  (MBSE),  the  concept  of  faster- 
better-cheaper  has  re-emerged,  albeit  under  new  monikers.  The  standard  INCOSE  MBSE 
briefing  (MBSE  Workshop,  February  2010)  promises  quality  and  performance  improvements 
with  enhanced  rigor  and  precision,  improved  stakeholder  communication,  and  better 
management  of  complexity.  Others  tout  MBSE's  ability  to  accelerate  the  systems  engineering 
effort  as  well  as  the  overall  system  life  cycle. 

As  we  seek  to  transform  the  practice  of  systems  engineering  to  better  face  the  complexities 
and  constraints  of  today,  we  must  ensure  that  we  maintain  our  own  balance.  We  must 
promise  improved  results  in  order  to  justify  the  cost  -  and  the  risk  -  of  adopting  new 
practices.  However,  we  must  ensure  that  we  don't  over  promise  and  under  deliver,  or  the 
legacy  of  MBSE  will  be  landmark  failures  rather  project  success.  As  we  seek  to  justify  the 
adoption  of  new  technologies  and  new  approaches,  are  we  simply  falling  into  an  old  trap, 
retracing  the  steps  of  Goldin's  previous  doomed  journey?  Or,  through  a  skillful  blend  of 
systems  engineering  and  project  management  approaches,  can  we  actually  achieve  the  vision 
of  faster-better-cheaper?  If  so,  what  frameworks  must  we  adopt  as  systems  practitioners  and 
what  changes  must  we  make  as  project  managers? 

Presenter  Biography 

David  Long  founded  Vitech  Corporation  in  1992  where  he  developed  and  commercialised 
CORE®,  a  leading  systems  engineering  software  environment  used  around  the  world.  He 
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continues  to  lead  the  Vitech  team  as  they  deliver  innovative,  industry-leading  solutions 
helping  organizations  to  develop  and  deploy  next-generation  systems. 

For  over  twenty  years,  David  has  focused  on  enabling,  applying,  and  advancing  model-based 
systems  engineering  (MBSE)  to  help  transform  the  state  of  the  systems  engineering  practice. 
He  has  played  a  key  technical  and  management  role  in  refining  and  extending  MBSE  to 
expand  the  analysis  and  communication  toolkit  available  to  systems  practitioners.  David  is  a 
frequent  presenter  at  industry  events  worldwide  delivering  keynotes  and  tutorials  spanning 
introductory  systems  engineering,  the  advanced  application  of  MBSE,  and  the  future  of 
systems  engineering.  His  experiences  and  efforts  led  him  to  co-author  the  book  A  Primer  for 
Model-Based  Systems  Engineering  to  help  spread  the  fundamental  concepts  of  this  key 
approach  to  modern  challenges.  In  2006,  David  received  the  prestigious  INCOSE  Founders 
Award  in  recognition  of  his  many  contributions. 

Presentation 


Faster,  Better,  Cheaper  - 


David  Long 
Vitech  Corporation 
Blacksburg,  Virginia,  USA  p-.t 
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The  Rise  of  Faster,  Better, 
and  Cheaper  (FBC) 

•  Launched  in  1992  by  NASA  Administrator  Dan  Goldin 

•  Sought  to  improve  cost,  schedule,  and  performance 
simultaneously  in  developing  high  tech  systems 

•  Launched  16  missions  during  an  8  year  period 

-  5  missions  to  mars 

-  1  mission  to  the  moon 

-  3  space  telescopes 

-  2  comet  and  asteroid  rendezvous 

-  4  Earth-orbiting  satellites 

-  1  ion  propulsion  test  vehicle 

•  9  of  the  first  10  missions  succeeded 

2012  DSTO  MBSE  Symposium 


The  Fall  of  FBC  -  The  Twin  Mars 
Mission  Disasters  of  1999 


•  Mars  Climate  Observer 

—  Lost  communication  during  orbital 
insertion 

—  Cause  of  failure:  units  error  (imperial 
vs  metrics)  resulted  in  incorrect 
atmospheric  insertion  and 
disintegration 


•  Mars  Polar  Lander 

-  Failed  to  reestablish  communication 
after  descent 

-  Likely  cause  of  failure:  premature 
engine  cut  off  causing  the  lander  to 
impact  at  a  high  velocity 
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The  Fall  of  FBC,  cont. 

"FBC  (resulted  in)  reduced  workforce  capability; 
increased  safety  risks;  and  minor  oversights  that 
resulted  in  lost  spacecraft " 

International  Federation  of  Professional  and  Technical  Engineers,  2003 

"FBC  should  be  thrown  in  the  waste  basket." 

US  Senator  Kay  Bailey  Hutchinson,  2003 


The  "Iron  Triangle"  of 
Project  Management 


Funding  margin 
for  under 
performance 


Over  cost  or 

Over  cost  or 

under 

over 

performance 

schedule 

Schedule  margin  for 
over  target  baseline 
(OTB) 


Technical 

Performance 


Over 

schedule  or 
under 
performing 


Schedule  margin  for 
underperformance  or 
schedule  extension 


r 

Schedul 

L 

A 

Today's  management  mantra  -  "pick  any  two" 
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Trading 

Cost,  Schedule, 
and 

Technical 
Performance  is  a 
Ponzi  Scheme 


When  we’re  on 
baseline,  the  algebraic 
relationship  between 
C,S,P,  means  when 
there  is  a  change 
everyone  looses 


lew>»  4  Fowle*.  Copyright  '£2010 


w 


Charles  Ponzi, 

Bom  March  3,  1882,  Italy. 
Died  Jan  18,  1949,  Brazil. 
Served  5  years  federal  prison, 
9  year  state  prison, 
deported  to  Italy. 


2012  DSTO  MBSE  Symposium 


■ 


Model-Based  Systems  Engineering 


A 


V 


Formalizes  SE  practice 
through  the  use  of  models 

Broad  in  scope 


Life  Cycle  Support 


Concept-  Design-  Production-  Utilization-  Support-  Retirement 


,.-~v 


-  Integrates  with  multiple 
modeling  domains  across  life 
cycle  from  SoS  to  component 

Results  in  \ 

quality/productivity 
improvements  &  lower  risk 


-  Rigor  and  precision 


-  Communications  among 
system/project  stakeholders 


Management  of  complexityy 


c 

o 


2 

cm 

<v 


m 

U 


2 


Reprinted  from  INCOSE  Model-Based  Systems  Engineering  Workshop,  February  2010 
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\wOii  i  vi  u  ji _  l/cii  vci  ivi^/ie;: 

A  Tale  of  Two  Scopes  (Control  vs 


I nfli  ionro^ 


if  we  focus  on  benefits  achieved  in  the  full  product 


Faster,  Better,  Cheaper  with  MBSE: 
The  Law  of  Conservation  of  SE 


" The  amount  of  systems 
engineering  required  for 
a  given  project  is  fixed. 
You  don't  get  to  choose 
how  much  SE  you  do. 

You  simply  get  to  choose 
when  you  do  it  (upfront 
or  during  l&T),  how 
much  positive  impact  it 
has,  and  how  much  it 
costs. " 

-  Jim  Long 


Factor-of-100  Growth  in  Software  Cost-to-Fix 

1000  r 

NM*  _  - 


Requirements  Design  Cod*  D*v*lopmen«  Acceptance  Operation 

T*«  Test 

Phase  in  which  defect  was  fixed 


CeBase  Software  Defect  Reduction  Top-10  List,  Basili  and  Boehm, 
January  2001 
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MBSE  for  Increased  Lifecycle  Quality 

>> 

Jr  Z'  /Z\  /x\ 

•  Early  identification  of  requirements  issues 

-  Missing  requirements,  conflicting  requirements,  and  general  defects 

♦  Enhanced  stakeholder  communication  to  enable  better  validation 

-  "We  fail  more  often  because  we  solve  the  wrong  problem  than 
because  we  get  the  wrong  solution  to  the  right  problem."  (Ackoff) 

♦  Disciplined  (and  defensible)  basis  for  decision  making 

-  Moving  beyond  "a  miracle  occurs  here"  analysis 

•  Enhanced  visibility  into  information  gaps  and  system  design 
integrity 

-  Model-driven  consistency  vs  document-based  hope 


•  Improved  specification  of  allocated  requirements  to  HW/SW 

•  Reduction  in  design  errors  reaching  integration  &  test 

•  Rigorous  traceability  from  need  through  solution 


MBSE  for  Reduced  Lifecycle  Cost 


Earlier  error  detection  and  reduced  rework 

Early/on-going  requirements  validation  and  design 
verification 

Reduced  cost  of  integration  &  test 
Reuse  across  divergent  products 

Identification  and  adoption  of  system  patterns  and 
heuristics 

Improved  cost  estimates 

-  Insight  is  often  as  important  as 
reduction 

Reduced  cost  overruns 
through  higher  lifecycle  quality 
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MBSE  for  Accelerated  Capability 

Delivery 

Enhanced  individual  command  of  the  problem  and  solution 

—  Opportunity  to  work  at  "thinkspeed"  rather  than  document 
index  speed 

Improved  alignment  of  collective  team  understanding 

—  One  high-visibility  version  of  truth 
Reduction  of  rework 

Reuse  of  models  to  support  design/technology  evolution 
Streamlined  integration  &  test  through  fewer  errors 

Simplified  problem  resolution  (and  expanded  options) 
through  early  detection 

Improved  impact  analysis  of  requirements  changes 
Knowing  when  you  are  done! 

Reduced  schedule  overruns  through  higher  lifecycle  quality 
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MBSE  for  Happier  Customers 


Enhanced  agility,  adaptability,  and 
responsiveness  to  change 

Improved  communication  &  insight 


Increased  confidence  through  argumentation 
and  command  of  the  problem  and  solution 
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BUT  WHAT  IF  I  MUST  DO  MBSE 
FASTER,  BETTER,  OR  CHEAPER 


Moving  Beyond  Our  Entrenched 


Waterfall  Mindset 


Source  Requirements  Domain 


Behavior  Domain 


Test  &  Evaluation  Domain 
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The  Problem  of  Entrenched  Stovepipes 


Architecture 


Synthesis 

Y 

X 

"-v 

'vPHysica 
Architecture 
Database 


fication 


Separating  the  domains  complicates  the  critical  SE  effort 
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Optimizing  MBSEfor  Quality 

•  Defend  the  existing  SE  schedule  and  budget 

•  Invest  in  the  tools,  training,  and  experience 
appropriate  for  your  project 

•  Enjoy  the  SE  and  lifecycle  benefits  listed  previously 

•  Maximize  project  degrees  of  freedom  as  you  apply  the 
MBSE  approach 
—  MBSE  technology  adoption 

-  Exploration  of  alternatives 

-  Analysis  through  executable 
models 

-  Reduction  of  risk 


The  scenario  we  hope  for! 
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Optimizing  MBSE  for  Schedule 
and/or  Budget 

•  Realize  inherent  savings  from  MBSE  transformation 

-  Reduced  (eliminated)  specification  production  costs 

-  Reduced  cost  of  change  request  /  impact  analysis 

-  Enhanced  team  productivity 

-  Enhanced  team  comprehension  by  eliminating  the  "plague  of  vague" 

-  Enhanced  process  efficiency  and  effectiveness 

•  Reduce  team  size 

•  Ask  "who"  questions  rather  than 
"what"  /  "how"  questions 

-  Who  has  done  this  before  such 
that  I  can  reuse  models  or 
patterns? 

•  Sacrifice  level  of  detail,  not  quality, 
consistency,  or  completeness 


The  scenario  we  will  eventually  face 
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Faster,  Better  Cheaper  is  Possible: 
An  Integrated,  MBSE  Approach 


Provides  discipline  and  structure 
Enhances  communication 


Increases  quality 
Reduces  risk 


Ensures  convergence  through  layered  approach 

Speeds  delivery  and  enhances  agility,  especially 
in  the  face  of  change 

Accelerates  (radically)  the  exploration  of 
revisions,  alternatives,  and  variants 


20 


Selling  the  Benefits  of 
Model-Based  Systems  Engineering 


•  Realize  that  faster,  better,  cheaper  is  possible 
—  But  understand  the  "silver  bullet  syndrome" 

•  Focus  first  on  lifecycle  value 

•  Argue  by  analogy 

—  "Would  we  perform  CAD  or  integrated  circuit  design  by  hand?" 

•  Move  the  conversation  from  price/cost  to  value  and  ROI 

•  Sell  technologies  only  to  technologists 

•  Avoid  telling  all  that  you  know 


•  Don't  underestimate  the  costs  of  transformatio 
training,  and  experience) 


—  The  curse  of  the  engineer 
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For  Additional  Information 

David  Long 
Vitech  Corporation 
2270  Kraft  Drive,  Suite  1600 
Blacksburg,  VA,  24060,  USA 
1.540.951.3322 
dlong@vitechcorp.com 
www.vitechcorp.com 
www.mbseprimer.com 
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4.  Lessons  Learned  in  Introducing  MBSE:  2009  to  2012 


A.  Peter  Campbell 
University  of  South  Australia 


Abstract 

An  overview  of  the  lessons  that  are  emerging  from  recent  efforts  to  employ  MBSE  in  the 
development  of  large  complex  projects  in  both  the  defence  and  civilian  sectors.  A  broad 
interpretation  of  MBSE  will  be  taken  to  encompass  tool  systems  that  embody  the  spirit  of 
MBSE,  if  not  the  specific  modern  practice  arising  from  the  OMG/INCOSE  sources.  The  paper 
will  address  findings  on  lessons  learned  with  respect  to  process  development,  cultural 
resistance,  management  perception  and  training  methods  and  needs. 

Presenter  Biography 

A.  Peter  Campbell  returned  to  Australia  from  22  years  in  the  US  in  late  2000.  He  worked  on 
three  year  contract  (2004-07)  for  CSIRO  Complex  Systems  Science  Initiative  to  introduce 
complex  system  simulation  tools  for  agricultural  landscape  planning  and  critical 
infrastructure  analysis.  In  May  2004,  Peter  joined  the  Systems  Engineering  and  Evaluation 
Centre  (SEEC)  at  the  University  of  South  Australia  as  Professor  of  Systems  Modelling  and 
Simulation,  working  on  the  application  of  complex  adaptive  system  simulation  technology  to 
large  scale  system  integration  projects  at  UniSA.  Recent  research  includes  architecture  design 
for  model  based  systems  engineering  applications  to  support  evolvable  systems  integration 
management  and  the  development  of  software  agents  to  replace  humans  in  the  loop  in 
defence  T&E  environments. 

Now  in  Defence  and  Systems  Institute  (DASI)  at  UniSA  Peter  has  the  responsibility  for 
business  development  of  modelling  and  simulation,  particularly  in  the  defence  area.  October 
2010  joined  University  of  Wollongong  as  Professor  of  Infrastructure  Modelling  in  the  SMART 
Infrastructure  Facility  while  continuing  at  UniSA.  Work  is  in  the  area  of  the  application  of 
ABM  and  MBSE  to  the  improvement  of  the  management  of  large  infrastructure  development 
projects,  with  a  specific  project  to  develop  an  ABM  of  the  interaction  between  transportation 
needs  and  changing  demographics  in  metropolitan  Sydney. 

Prior  to  2000  Peter  worked  at  Argonne  National  Laboratory  in  US  for  15  years  where  he  was 
involved  in  the  development  of  advanced  agent  based  modeling  methods  with  application  to 
decision  support  tools  for  defence  and  industry  applications.  Project  lead  and  designer  for 
ABM  tools  for  energy  supply,  drug  interdiction,  hospital  work  flow,  logistics  operations  and  a 
range  of  defence  applications 
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Presentation 


Lessons  Learned  in  Introducing 
MBSE  -2009  to  2012 

By 

A.  P.  Campbell 
UniSA,  Nov.  2012 


Introduction 

•  This  presentation  is  based  on  a  survey  done 

for  DSITA  in  late  2012 

•  Several  themes  became  apparent 

—  Huge  amount  of  work  going  on  globally  at  the  SOS 
level  and  organisational  modelling 

—  Further  tool  development,  and  especially  the 
production  of  domain  specific  templates  and 
profiles  make  things  a  bit  easier 

—  Still  a  dearth  of  specific  ROI  numbers 
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Older  Lessons  - 1 

•  Organisational  cultural  change  is  generally  needed  -  so  there 
needs  to  be  specific  effort  made  to  do  this 

•  Upper  management  support  is  essential  -  upfront  costs,  for 
tools,  training,  infrastructure,  schedule 

•  There  remains  a  dearth  of  expertise,  so  early  work  needs  to 
be  planned  for  this  constraint 

•  Frequent  -  daily  -  interactions  are  needed  to  ensure 
processes  remain  coherent  at  the  beginning  of  project 

•  The  models  must  continue  to  evolve  -  model  maintenance  is 
often  neglected  because  it  is  seen  as  expensive  -  also 
requires  some  organisational  change 


Some  Sources  -1 

•  Some  of  the  important  sources  emphasising 
the  need  for  addressing  cultural  change  and 
obtaining  management  support: 

—  Rolls-Royce 
-  NASA/JPL 
-UK  MOD 
-EELT 

—  Crescendo  -  EADS  and  ~  50  others 
—  NDIA  ! 
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Older  Lessons  -  2 

•  Real  examples  are  needed  to  convince  others 
of  the  benefits 

•  It  is  hard  to  do  -  just  do  it,  but  on  a  small  scale 
first 

•  Some  of  the  benefits  are: 

-  Reduced  time  to  completion 
—  Earlier  risk  identification 
—  Reduced  rework 
—  Better  prospects  for  re-use 


Older  Lessons  -  3 

•  Benefits  (continued) 

—  Enhanced  interoperability 

—  Captures  lifecycle  information  for  future  upgrades 
—  Improved  reliability 

—  Models  have  more  to  contribute  than  just 
supplying  quantitative  analysis  -they  improve 
capture  and  description  of  design  and  are 
powerful  first  steps,  immediately  improve 

communication  and  understanding  ('The  benefits  of 
this  would  be  difficult  to  overstate"  JPL) 
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Newer  Lessons  - 1 

•  There  are  psychological  reasons  why  it  is  hard 
as  well  as  cultural  ones.  ("The  human  mind  wants 

positive  progress.  In  engineering  this  is  seen  in  the  tendency  to 
prioritize  developing  solutions,  and  working  the  first  feasible  idea  - 
an  illusion  of  progress.  We  must  recognise  that  this  is  natural 
human  behaviour,  and  take  explicit  steps  to  avoid  it."  Beasley  2012) 

•  Organisational  structure  change  to  remove 
stove  piped  responsibilities 

•  Leverage  learning  with  synergistic  work  - 
related  to  "just  do  it"? 


Some  Sources  -2 

•  Correct  structuring  of  projects  is  necessary  to 
ensure  maximum  benefit  for  use  of  MBSE 
—  NDIA 
-EELT 
—  Aster  S.p.A 

—  SOS  -  several  of  the  presentations  atTTCP  JSA 
TP4,  2012 
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Newer  Lessons  -  2 

•  Suggested  team  organisation  for  a  large 

project  -  3  tiers:  (From  JPL  Europa  study) 

-  Small  core  of  ~  6  modellers  -  but  don’t  isolate  it 

-  Larger  group  of  ~  20  modelling  savvy  engineers  -  where  the  top  level 
expertise  resides,  such  as  the  system  architect 

-  The  rest  of  the  project  personnel 

•  Pay  attention  to  the  level  of  detail  that 
modelling  is  taken  to  -  duality  OK  in  large 
project  as  long  as  consistent  at  top  level 

•  Useful  for  supporting  virtual  integration 


Newer  Lessons  -  3 

•  Helps  to  overcome  the  human  tendency  to 
read  what  we  think  text  says,  rather  than 
what  it  actually  says 

•  Keep  model  and  analysis  separate  -  enables 
model  re-use  on  later  analyses  of  different 
options 

•  Usefulness  of  "socialising",  managing  staff 
rotation  in  long  running  projects,  need  for 
total  involvement  of  all  team  members 
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Some  Sources  -3 

—  NASA/JPL  -  space  networks  project 

—  WSAF 

—  SOS  -  several  of  the  presentations  atTTCP  JSA 
TP4,  2012 

—  Renault 


Major  Program  Applications 

•  CRESCENDO  (Realisation  system  and 
Intervention  system)  EADS  et  al  (and  VIVACE) 

•  SWTFS  (Submarine  Warfare  Federated 

Tactical  System  )  13%  savings  in  SE  work,  25%  reduction 
in  capability  dev't  work  and  10%  quicker  than  using  DOORS  in 
baseline  management 

•  EELT 
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Project  Level  Applications/Studies 

•  Europa  project  (JPL,  Bayer) 

•  Gripen  (  SAAB,  Herzog) 

•  SysML  vs  Siemens  Team  Centre  (Boeing,  Gau) 

•  A  PLM  system  for  auto  manufacture  (Ciriello) 

•  Another  comparison  study  (BAE,  Wilber) 

•  MBSE  savings  (Raytheon,  Saunders) 

•  Manufacturing  System  design  (GIT,  Batarseh) 

•  Requirements  for  defence  systems  (ASTER,  Petrinca) 

•  US  FAA  NextGen 


LMCoJSF  Modelling 

The  Lockheed  Martin  Simulation  and  Systems  Integration 
Laboratories  Ft.  Worth  Texas 

•  Not  much  to  do  with  MBSE  as  we  are  talking  about  it 
here,  but  I  want  to  tell  you  about  it  anyway  -"Virtual 
to  real" 

-  29  Simulation  labs  for  F16,  F22,  F35,  plus  a  complete 
system  flying  in  a  737  plus  another  complete  system  in  an 
F35  body  on  special  mount  on  top  of  one  of  the  buildings 

-  Flight  Control  System,  VTL  system,  Mission  system,  6  DoF 
simulator,  even  a  PC  version  to  introduce  FCS  system,  etc 

-  Stove  piped  until  very  late  1990s  -  DOD  5000  series 
standards  required  huge  amount  of  work  to  integrate 

—  Would  have  been  much  quicker  and  cheaper  if  they  had 
been  able  to  use  todays  tools 


UNCLASSIFIED 


31 


DSTO-GD-0734 


UNCLASSIFIED 


Major  SOS  Research  and  Programs 

•  DANSE  -  Designing  for  Adaptability  and  evolutioN  in  System  of 
systems  Engineering  -  EU  FP7 

•  SAVI  -  System  Architecture  Virtual  Integration.  International 
effort  through  the  Aerospace  Vehicle  Systems  Institute  -2006- 
2016  (Standard  data  storage  and  exchange  constructs  enable  early 
virtual  integration  of  models  distributed  across  the  supply  chain.  A 
monolithic  solution  is  not  practicable.) 

•  Architecture  framework  for  the  Renault  System  and  Safety 
data-model 

•  US  DOD  Implementations  and  Initiatives  -  briefly  shown  on 
next  5  slides:  ERS,  CREATE,  AVM,  FACT,  DISA 


MBSA  as  a  Foundation  for 
Engineered  Resilient  Systems 

Systems  Representation  and  Modeling 

-  Physical,  logical  structure,  behavior,  interactions,  interoperability... 


Collaborator*  Analysis  of  Enginatring  Issues  and  Impacts 


Alternatives 


Kept  Longer 


Explored 


Deeper 


Characterizing  Changing 
Operational  Contexts 

-  Deep  understanding  of  warfighter  needs, 
impacts  of  alternative  designs 


Cross-Domain  Coupling 


-  Model  interchange  &  composition 
across  scales,  disciplines 


Data-driven  Tradespace 
Exploration  and  Analysis 

-  Multi-dimensional 

generation/evaluation  of 
alternative  designs 


Refinement 
Context  of 
Operational 
Missions 


Collaborative  Design  and  Decision  Support 

-  Enabling  well-informed,  low-overhead  discussion, 
analysis,  and  assessment  among  engineers  and 
decision-makers 
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Computational  Research  and  Engineering 
Acquisition  Tools  and  Environments  (CREATE) 

Enable  major  improvements  in  DoD  acquisition  engineering 
design  and  analysis  processes,  by  developing  and  deploying 
scalable  physics-based  computation  engineering  software 
products 


What  is  CREATE? 


Multi  Physics-Based  Performance  Analysis 
Increases  Productivity  for  Complex  Systems 


CREATE  is  a  DoD  program  to  develop  and  deploy 
multi  physics-based  software  for  engineering  design 
and  analysis  of: 

Air  Vehicles  (AV) 

-  Aerodynamics,  structural  mechanics,  propiision,  control,  ... 

Ships 

-  Shock  vulnerability,  hydrodynamics,  concept  design 

Radio  Frequency  (RF)  Antennas 

-  RF  Antenna  electromagnetics  and  integration  with  pletfcrms 

Mesh  and  Geometry  (MG)  Generation 

-  Rapid  generation  of  mesh  and  geometry  representations 


CREATE  tools  support  all  stages  of  acquisition  from  rapid 
early  stage  design  to  full  life-cycle  sustainment 


SJioek  vuIntuMty 


Military  platforms  witft  antennas 


Reduced  design  and  development  time 

-  Highly  scalable  computational  performance  analysis  of 
virtual  prototypes  reduces  the  need  to  test  real  prototypes 

Process  converges  much  faster 

-  Process  is  flexible,  very  responsive  to  new  requirements 

-  Design  flaws  early  in  process  reducing  rework 

-  Systems  I  ntegrati  on  happens  at  every  step  of  the  process 


□klitilfii  SbfcmeitA:  Afproe d forpiBfc  itlan;  ditrbifai  k  nlnfed. 


MBE:  Adaptive  Vehicle  Make 
(AVM) 

•  DARPA  program  to  address  the  technical  problem  at  the  'seams’  - 
between  stages  of  production,  between  components,  and  between 
organizations.  3  major  parts:  Shorten  development  times  for 
complex  defense  systems;  Shift  product  value  chain  toward  hi-value 
designs:  Democratized  design 


Moving  from  parts  to  systems: 
DARPA  Adaptive  Vehicle  Make 


Model  Library 


Collaborrton  Capability 

© 


©  .V<Q 

Vex 


Vy 


■,SlL- 


<F 


Design  Manufacturing  Next  Generation 
Competitions  Foundry  Infantry 

Fighting  Vehicle 


High  School  Outreach 
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MBE:  Framework  for  Assessing 
Cost  and  Technology  (FACT) 


© 

Q 

|  -ST*|| 

Succes*  Story-  Modollnf  and  Sirmibtio*  bfts+d  Sy»t«<ns  Enf  inform* 

MARINE  PERSONNEL  CARRIER 

RB 

A  USMC  M&S  Systems  Engineering  process 
enabling  rapid  trade  space  and  alternative 
analysis  by  simultaneously  exploring  the  trade 
space  between  cost,  schedule,  performance 
and  risk 


Suite  of  M&S  Integrated  Tools 
Developed  for  MPC 


MPC:  Integrated  M&S  Framework 


Recomneiwkticms  fa  aVatoiKad, 
achievable  requirements  do  curt*  it 
for  MPC 


C  Only  way  to  understand  trade-off  between  requirements  is  to 

understandtfie  otivsics  of  the  problem 


MBSE  as  Framework  for  Overall 
DISA  SE  Process 


Use  as  the  model 
and  environment 
to  support  their 
role  as  enterprise 
engineering  for 
common  services 
in  the  DoD  IT 
infrastructure 

Provides  a 
common 
framework  ('Systems 
level'  jfor  diverse 
and  distributed 

('Sub  systems  level') 

design  and 

engineering 

activities 


34 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0734 


Tools 

•  Kalawsky  et  al  (2012  unpublished)  Model  based 
system  design  and  HIL  simulation  for  system 
verification  with  model  transformation  tools  to 
facilitate  bi-directional  transformation  of  a  Rhapsody 
model  to  a  Simulink  model 

•  Tool  set  for  developing  Aviation  Safety-Critical 
Runtime  with  Ability  to  Certify  to  Do-178B  Level  A  - 
At  ego 

•  Dassault  Catia,  Siemens  NX  -  fully  integrated  PLMs 

•  OMG  Model  Interchange  Working  Group 
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5.  Theatre  of  Operations:  An  entertaining  problem 

Tommie  Liddy1,  Michael  Waite1,  Paul  Logan2  and  David  Harvey1 
aAerospace  Concepts  and  2Empel  Solutions 


Abstract 

System  requirements  and  constraints  specify  how  a  system  must  look,  feel  and  function;  but  it 
is  the  needs  of  the  users  and  stakeholders  that  give  the  system  its  raison  d'etre.  If  a  valid 
solution  system  is  to  be  delivered,  the  end-users'  needs  must  be  correctly  identified,  within 
the  stakeholders'  constraints.  While  this  process  forms  an  essential  part  of  the  concept  phase 
of  the  engineering  lifecycle,  it  is  often  left  under-done,  with  needs  attributed  to  the  general, 
non-specific  "user".  Since  needs  vary  per  user,  it  is  of  critical  importance  to  identify  who  the 
end-users  are,  what  their  role  in  the  operational  behaviour  of  the  system  entails,  and  from 
where  they  came.  Similarly,  when  considering  stakeholder  constraints  it  is  necessary  to 
identify  who  the  stakeholders  are,  what  their  influence  on  the  system  entails,  and  from  where 
they  view  the  system. 

One  of  the  more  significant  changes  to  the  US  Department  of  Defense  Architecture 
Framework  (DoDAF)  from  version  1.5  to  2.0  is  the  manner  in  which  operational  entities  are 
considered.  In  version  2.0,  'Performers'  were  added  to  the  DoDAF  meta-model  to  capture 
those  entities  responsible  for  performing  the  representative  activities  which  make  up  the 
operational  scenarios.  These  Performers  replaced  the  often  over-used  and  poorly-understood 
'Operational  Nodes'. 

Additionally,  capability  stakeholders  offer  requirements,  in  the  form  of  constraints,  which 
bound  the  problem  space.  These  constraints,  in  combination  with  the  user  needs,  allow  the 
systems  engineer  to  understand  the  operational  concept  of  the  capability.  User  needs  and 
other  stakeholder  requirements  are  identified  and  described  from  the  perspective  of  a 
particular  class  of  stakeholder.  To  address  these  perspectives,  each  stakeholder-class  and  their 
environment  is  modelled  with  emphasis  on  identifying  what  they  need  the  system  of  interest 
to  be  or  not  to  be  -  i.e.  what  they  need  to  achieve  (goals  and  objectives),  and  to  what  they  need 
to  conform  (limitations  and  constraints).  The  aggregate  model  of  all  stakeholders  is  thus  an 
integrated  architecture  description  of  the  problem  space  (IS042010  2008). 

Effective  needs  analysis  requires  complete  understanding  of  the  users  and  how  they  act  as 
operational  performers,  their  roles,  and  the  organisations  to  which  they  belong.  This 
presentation  provides  an  entertaining  yet  rigorous  example  and  uses  colloquial  language  to 
describe  in  readily  understood  terms  a  robust  needs  analysis  methodology  that  is  effective, 
efficient  and  also  compliant  with  the  Defence  Architecture  Framework  (DAF).  The  example 
demonstrates  the  application  of  a  model-based  approach  to  concept  engineering  and,  in 
particular,  how  a  better  understanding  the  'performers'  leads  to  a  solid  basis  on  which  to 
design  a  solution. 
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development,  he  is  also  involved  in  applying  the  tool  and  approach  to  capability  definition  in 
major  Australian  Defence  projects. 


38 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0734 


Presentation 


Theatre  of  Operations 


Tommie  Liddy  David  Harvey 

Aerospace  Concepts  Pty  Ltd  Aerospace  Concepts  Pty  Ltd 


Michael  Waite 

Aerospace  Concepts  Pty  Ltd 


Aerospace  Concepts  Pty  Ltd  ©  2012 


Paul  Logan 

Empel  Solutions  Pty  Ltd 

MBSE  Symposium  2012  -  Theatre  of  Operations 


Presentation  Scope 


•  The  “context” 

»  Model-Based  Systems  Engineering  (MBSE) 

•  User  Needs 

-  Operational  analysis 

-  The  performer 

•  The  “solution” 

•  The  methodology  we  use  to  keep  focus  on  the  users 

•  Intent  and  focus  on  user  needs 

•  An  “entertaining”  example 

•  Theatre  company  -  The  Scottish  Play 

•  Abstraction  to  general  model 


Aerospace  Concepts  Pty  Ltd  ©  2012 


MBSE  Symposium  2012  -  Theatre  of  Operations  2 


UNCLASSIFIED 


39 


DSTO-GD-0734 


UNCLASSIFIED 


What  is  MBSE 


•  What  is  Systems  Engineering? 

-  Systems  engineering  involves  taking  a  structured 
approach  to  definition,  design  and  implementation 
of  systems  that  address  defined  user  problems 

•  What  pushes  us  towards  Model-Based? 

-  Outsourcing  (Sparrow  &  Wegner  2011) 

•  Recording  systems  knowledge,  while  retaining  the 
understanding  of  how  to  find  it 

-  Increasing  complexity  of  projects  vs  understanding 
capacity  (Metcalfe’s  Law  vs  Miller’s  'Magical  Number’) 

-  Teams  of  Systems  Engineers 
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Where  do  we  use  MBSE 


MBSE  can  aid  in  defining  needs  and  functionality  early 
in  the  development  cycle  and  then  proceeding  with 
design  synthesis  and  system  validation  while  considering 
the  entire  systems  lifecycle 


Utilization 

Conception 

Development 

Production 

Retirement 

Support 
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Benefits  of  MBSE 


•  Focus  on  the  information  of  and  about  the  system  leads  to  a 
number  of  benefits 

-  Traceability 

•  Links  established  and  maintained  as  part  of  the  approach 

-  Consistency 

•  ‘Single  source  of  truth’ 

-  Adaptability 

•  Any  number  of  views  or  documents  can  be  produced  as  snapshots  of 
slices  of  the  model 

-  Robustness  &  information  sharing 

•  System  information  made  explicitly  clear 

•  Domain  specialist  views  are  possible  -  without  neglecting  the 
interconnected  nature  of  domains 
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MBSE  in  the  Conception  Phase 


•  Conception  phase 

-  Needs  analysis 

-  Requirements  analysis 


Aerospace  Concepts  Pty  Ltd  ©  2012 


MBSE  Symposium  2012  -  Theatre  of  Operations  6 


UNCLASSIFIED 


41 


DSTO-GD-0734 


UNCLASSIFIED 


MBSE  in  the  Conception  Phase 


•  A  detailed  look  at  the  conceptual  phase,  this  is  how  we  gather  the 
User’s  needs 
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User  Needs 


When  MBSE  is  applied  to  capability  definition  we  are 
able  to  help  people  Ask  for  what  they  Need,  not  just 
what  they  Want,  ensuring  the  User  is  King 
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An  Entertaining  Example 


•  The  CONOPS:  A  travelling  theatre 
company,  putting  on  “The  Scottish  play” 
in  a  new  town. 


-  There  is  a  Theatre  Company  (the  Organisation) 

-  Who,  when  mobilised  to  put  on  a  performance, 
are  given  roles  to  play 


-  It  has  Actors,  Crew  and  Management  (the 
“Performers”) 

-  And  activities  to  perform  (Scenarios  and 
Vignettes) 
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The  Scottish  Play 


Theatre  Company 
Organisation 

Roles  in 

The  Scottish  Play 

The  Performers 

Cast 

Principal  Actor 

Macbeth 

Lady  Macbeth 

Support  Actor 

Macduff 

Duncan 

Banquo 

Banquo's  ghost 

Angus 

Ross 

Witches  three 

Others... 

Crew 

Back  Stage  Crew 

Stage  Hand 

Lighting  guy 

Sound  guy 

Wardrobe 

Stage  manager 

Production 

Management 

Producer 

Director 

Marketing 

Playwright 
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The  Scottish  Play 


•  Our  “Campaign”  involves  the  theatre  company  putting  on  a 
performance 

-  Note:  that  this  is  a  simplified  model  for  use  in  this  example,  and  is  therefore 
not  intended  to  be  complete 

*  Each  activity  is  decomposed  down  until  the  activity  is  performed 
by  a  single  Performer  (i.e.  a  user  class) 
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Thunder.  Enter  the  Three  Witches 


•  An  example  Vignette  in  our  Campaign... Act  I  Scene  III 


Aerospace  Concepts  Pty  Ltd  ©  2012  MBSE  Symposium  2012  -  Theatre  of  Operations  12 


44 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0734 


UNCLASSIFIED 


45 


DSTO-GD-0734 


UNCLASSIFIED 


Grouping  Users 


•  The  Witches  Three 

-  The  three  witches  are  aggregated  up  to  be  a  single  Performer 

-  This  decision  is  based  on  the  level  of  detail  in  the  Activity 
Model  and  the  commonality  of  the  Performers 

-  We  want  to  keep  the  knowledge  model  as  simple  as  possible 
to  elicit  all  the  user  needs,  but  no  simpler 
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General  Model  Architecture 
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Conclusion 


•  MBSE  can  aid  in  defining  needs  and  functionality  early  in 
the  development  cycle 

•  By  applying  analysis  and  rigor  to  the  development  of  a  set 
of  Users,  or  User  classes,  we  can  develop  a  concise  yet 
complete  set  of  user  needs 

•  Just  as  one  user  can  have  many  needs,  many  users  can 
have  a  shared  need 

•  The  person  developing  the  user  needs  should  have  a  good 
understanding  of  the  user,  and  interact  with  them  where 
possible,  to  enable  user  interests  to  be  appropriately 
defined 
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Take  Home  Message 


User  needs  and  other  stakeholder 
requirements  should  be  identified 
and  described  from  the  perspective  of 
each  class  of  stakeholder 
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6.  Using  MBSE  to  Understand  the  Link  between 
Capability  Acquisition  Projects  and  DSTO  Technology 

Advice 


Simon  Demeduik1,  Wayne  Power2  and  Brett  Morris1 
aMaritime  Platforms  Division,  DSTO  and  2Weapons  Systems  Division,  DSTO 

Abstract 

One  role  performed  by  technology  Groups  within  DSTO  is  the  provision  of  whole  of  platform 
advice  to  Defence  capability  acquisition  projects  during  the  needs  and  requirements  phases  of 
the  capability  development  lifecycle.  At  present  the  process,  or  system,  that  links  the  request 
for  advice  from  a  capability  acquisition  project  stakeholder  to  the  analysis  and  advice 
provided  by  DSTO,  is  not  clearly  understood  or  defined.  This  lack  of  clarity  can  influence  the 
form  and  content  of  the  advice  provided  by  permitting  misinterpretation  of  the  intended 
purpose  of  the  advice  by  the  DSTO  Groups  and/or  misunderstanding  on  the  part  of  the 
capability  stakeholders  as  to  the  type  of  analysis  required  and  the  expected  bounds  of  validity 
of  the  advice.  The  role  that  DSTO  provides  to  the  greater  Defence  organisation  is  analogous  to 
many  customer  /  service  provider  relationships  in  industry,  thus  this  lack  of  clarity  between 
customer  requirements  and  technical  advice  provided  is  broadly  applicable. 

In  order  to  gain  a  better  appreciation  of  the  process  of  linking  requests  for  advice  to  analysis, 
two  main  aspects  need  to  be  considered,  one  that  resides  at  the  Group  level  and  the  other  at 
the  enterprise  level.  The  enterprise  level  considers  the  wider  provision  of  advice  to  Defence 
acquisition  projects  by  DSTO.  At  this  level,  the  problem  is  ill-structured  and  contains  a 
multitude  of  stakeholders.  A  soft  systems  approach  is  one  method  that  could  be  beneficial  in 
enhancing  our  understanding  and  helping  to  define  the  system  at  this  level.  This  presentation, 
however,  focuses  on  the  Group  level.  At  this  level,  the  problem  is  somewhat  simplified  due  to 
the  reduction  in  stakeholders,  processes,  analysis  tools  and  techniques,  nonetheless,  the 
problem  space  is  still  non-trivial.  It  is  anticipated  that  by  defining  the  system  at  the  Group 
level,  a  more  informed  subsequent  exploration  of  the  enterprise  level  could  be  conducted. 

To  address  the  problem  at  the  Group  level,  a  systems  engineering  approach  has  been  deemed 
as  suitable.  This  is  based  on  the  authors'  contention  that  the  problem  at  hand  (i.e.  the 
provision  of  advice  due  to  a  request)  can  be  described  as  being  an  assemblage  of  elements,  in 
the  form  of  related  activities  and  processes  that  form  a  unitary  whole,  where  this  unitary 
whole  constitutes  a  system2.  In  this  instance,  an  Object-Oriented  Systems  Engineering  Method 
(OOSEM)  approach3,  along  with  IS015288,  has  been  adapted  and  adopted  to  the  development 
of  a  system  for  providing  advice  to  stakeholders  by  the  appropriate  Groups  within  DSTO. 


2  Blanchard,  B.  S.  and  Fabrycky,  W.  J.  (2006)  Systems  Engineering  and  Analysis.  4th  ed.  New  Jersey, 
Pearson  Prentice  Hall 

3  2.  Friedenthal,  S.,  Moore,  A.  and  Steiner,  R.  (2009)  A  Practical  Guide  to  SysML:  The  Systems  Modeling 
Language.  Burlington,  MA,  Morgan  Kaufmann  OMG  Press 
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This  presentation  will  cover  the  exploratory  research  and  concept  stages  of  the  development 
of  a  system  for  providing  advice  and  how  the  DSTO  Naval  Architecture  and  Platform  System 
Analysis  Group  and  the  Weapons  Capability  Analysis  Group  were  able  to  embed  MBSE  into 
the  activities  (for  example  the  user  requirements  elicitation  and  analysis)  that  were  conducted. 
The  presentation  includes  an  overview  of  the  user  requirements  elicitation  workshops  and 
their  outcomes.  Following  this,  a  discussion  on  some  of  the  common  themes  arising  from  the 
workshops  is  given.  Amalgamation  of  the  outcomes  of  the  workshops  to  potentially  develop  a 
common  framework  for  providing  technology  advice  is  discussed.  Some  of  the  initial  system 
component  feasibility  exploration  is  examined,  along  with  the  key  lessons  learned  from 
embedding  MBSE  into  the  system  development  process.  Finally,  with  the  increasing  use  of 
Model  Based  Systems  Engineering  (MBSE)  within  Defence  capability  acquisition  projects,  the 
potential  for  this  MBSE  approach  to  be  used  to  develop  a  linkage  between  a  project's 
knowledge  model  and  simulation  performed  within  DSTO,  will  be  discussed. 

Presenter  Biographies 

Simon  P.  Demediuk  obtained  a  Bachelor  of  Engineering  and  a  Bachelor  of  Science  from 
Swinburne  University  in  2009.  Since  then  Simon  has  worked  as  a  Defence  Scientist  at  DSTO. 
Simon  joined  Maritime  Platforms  Division  in  2010  working  for  the  Naval  Architecture  and 
Platform  Systems  Analysis  group  and  currently  works  on  development  of  analysis  tools  in 
relation  to  the  Future  Submarine  Program. 

Wayne  Power  graduated  with  honours  from  the  Queensland  University  of  Technology  (QUT) 
with  a  Bachelor  of  Engineering  (Aerospace  Avionics),  minor  in  Systems  Engineering.  He  has 
spent  the  last  six  years  working  in  Weapons  Capability  Analysis  within  DSTO's  Weapons 
Systems  Division  (WSD).  His  work  in  WSD  has  included  weapon  system  integration 
modelling  and  analysis,  but  the  major  focus  of  his  work  has  revolved  around  researching  and 
developing  the  Whole-of-System  Analytical  Framework  (WSAF).  The  WSAF  employs  a 
Model-Based  Systems  Engineering  approach  for  the  provision  of  cross-Defence  modelling, 
simulation,  analysis  and  Capability  Development  activities. 

Brett  Morris  is  a  Naval  Architect/ Systems  Engineer  who  joined  DSTO  in  2007.  He  has 
previously  worked  for  the  RAN  in  the  Directorate  of  Navy  Platform  Systems  and  is  currently 
working  in  the  fields  of  Naval  ship  concept  design,  structures  and  hydrodynamics,  along  with 
Systems  Engineering  applications  to  Naval  Architecture.  Brett  holds  a  Grad.  Dip.  In  Systems 
Engineering,  a  BE  (Nav.  Arch.)  and  is  currently  undertaking  part-time  research  towards  a 
PhD. 
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Presentation  Overview 


■  Background  -  need  for  the  work 

■  The  system  of  interest 

■  MBSE  approach 

■  User  Needs/Stakeholder  Requirements  Elicitation 

-  NAPSA 
■  WCA 

■  High-level  framework  for  an  interface? 

■  Current/Further  work 

■  Lessons  learned  on  using  MBSE  during  stakeholder  needs 
identification 

■  Conclusions 
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Background 

■  The  process  linking  information  request  to  M&S  and  advice  loosely 
defined 

■  Can  lead  to: 

-  Provision  of  advice  not  reflective  of  request 

-  Unrealistic  expectations  from  project 

■  Due  to: 

-  Analysts  lacking  clarity  of  purpose 

-  Purpose/capability  lost  in  translation 

■  Croup  level  focus 


■  Adopted  an  MBSE  approach  to  System  Development 
■Isa  common  framework  possible? 


■  MBSE  Capability  Models  taking  off  within  CDC  ->  Could  these  be  linked  to 
M&S? 
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System-of-lnterest 


Examples: 

•  SEA1000 
and  Land19 
Capability 
Models 

•  Operational 
Support 

•  Capability 
Assessment 

•  S&T 
Innovation 


Examples: 

•  ModelicaML 

•  C++ 

•  Relevant 
SMEs 
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MBSE  Approach 


■  Adopted  OOSEM  System  Specification  and  Design  Process  [1]  and 
Systems  Engineering  Handbook  [2]  (ISO/IEC1  5288  [3])  Exploratory 
Research  processes 

■  Mirrors  CDD  Process  [4]  -  i.e.  operational  scenarios  to  elaborate 
needs 

■  Tools 


■  Enterprise  Architect  (NAPS/ty 

■  CORE  (WCA) 

WSAF  Metamodel 


Manage 

Requirements 

Traceability 


Analyse 

Stakeholder 

Requirements 

i 


Analyse  System 
Requirements 

1 


Define  Logical 
Architecture 


Synthesise  Candidate 
Physical  Architectures 
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User  Needs/Stakeholder  Requirements  Elicitation  -  NAPSA 
Workshop  1 

■  Outline  the  session  and  define  ■  MBSE  performed  on-the-fly 
MBSE  terminology 

■  Elicit  need  statement 

■  Structured  Brainstorming  • 


Minimise  “SE”  discussion 


Elicit  Top-Level  “Use  cases”  (i.e.  questions  the 
group  has  been,  or  are  likely  to  be  asked) 

Rate  the  importance  of  each  operational  activity 
Elicited  Operational  Activities  fora  general  “Use 
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WSAF  Evolution 


DSTO  S&T  requirements 
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User  Needs/Stakeholder  Requirements  Elicitation  -  NAPSA 
Workshop  2 


Similar  participants  to  Workshop  1 
Review  of  the  need  statement 
Structured  Brainstorming 
Used  model  from  1st  workshop 

uc  tram*  analysis  J 


MBSE  performed  on-th e-fly 

Elaborated  Top-Level  Use  Case  FFBD  (operational 

activities) 

Elicited  operational  needs  and  constraints 


54 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0734 


UNCLASSIFIED  -  For  Public  Release 


User  Needs/Stakeholder  Requirements  Elicitation  -  NAPSA 
Workshop  3 

■  Elaborated  another  top-level  Use  Case 

■  Blank  Canvas 


■  Restricted  participants  to  5-8  operational  activities 
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Frameworks  for  Conducting  Analysis 

GUIDEx  [5] 


NATO  -  Conceptual  Model  Development  Process  [7] 
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A  Possible  High-Level  Framework  for  M&S? 


Client  Interaction 

Activities 

Actors 

Outputs 

•Client  engagement 

•DSTO/CDG/Project 

•Initial  Problem  Definition 

•Client/Service  provider 

Statement 

t  i  t  t  t 


Problem 
Formulation  and " 
Design 


Prepare  N. 


M&S  Input  \ 


M&S 


Data  / 


Execution 


Analysis^^  Reporting 


Activities 

•  Frame  analysis 

•  Determine 
outputs 

•  Negotiate 
analysis  activities 

•  Determine 
constraints 

•  Extract  relevant 
data 

•  Format  data 
•Treat  gaps  & 
assumptions 

•  Identify  risk  level 

•  Conduct  M&S 

•  Validate  results 

•  Identify  M&S 
bugs/errors 

•  Validate  data 
will  satisfy  SOW 

•  Analyse  M&S 
results 

•  Resolve  any 
validation 
issues 

•Prepare  results 
for  reporting 

•Assemble 

results 

•  Prepare  report 

•  Review  report 

•  Obtain  release 
approvals 

Actors 

•  DSTO/CDG/ 
Project  office 

•  Client/Service 
Provider 

•  DSTO  /service 

provider 

technology 

area 

•DSTO  /service 

provider 

technology 

area 

•  Other 

technology 

experts 

•DSTO  /service 

provider 

technology 

area 

•  Other 

technology 

experts 

•DSTO  /service 
provider 
technology  area 

•  Other 
technology 
experts 

•  Management 

Outputs 

•  Statement  of  work 
(SOW) 

•  Internal  analysis 
plan 

•Assumptions 

•  Resource 
requirements 

•  Security  needs 

•  Relevant  data 

•  Data  in  correct 
file  format 

•  Analysis 
uncertainty/risk 
level 

•  M&S  output 
data 

•  Error/issue 
log 

•  Updates  for 
executable 

•  Results  in 
useable 
format  for 
reporting 

•  Analysis 
issue  log 

•  Approved 
report  in 
format  that 
satisfies  SOW 
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So  What  -  Where  to  from  here? 


req  Identify  relevant  data  with  RFI  ^ 


(from  Operational 
Constraints) 
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Lessons  Learned 

■  Avoid  any  emphasis  on  “we  are  doing  SE” 

■  Be  aware  of  personalities  -  e.g. 

■  Functional  thinking  not  inherent  -  give  them  time  to  explore 

■  People  down  in  the  weeds 

■  Importance  of  a  broad  range  of  stakeholders 

■  By  the  third  NAPSA  workshop,  participants  had  process  buy  in 

■  Positive  feedback 

■  Able  to  work  with  a  blank  canvas 


■  Having  two  facilitators  at  NAPSA  workshops  was  beneficial 

■  You  can  perform  modelling  on-the-fly  -  and  it  aids  elicitation! 
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Conclusions 


■  Large  amount  of  Human/negotiating  activities  within  interface 

■  Possible  High-level  framework  only  applicable  to  Defence/DSTO  at 
present 

■  MBSE  on-the-fly  is  useful  in  concept  engineering  -  particularly  needs 
elicitation 

■  Potential  exists  to  link  some  of  the  identified  operational 
activities/functions  to  components  in  an  interface  between  MBSE 
capability  models  and  M&S 

■  This  is  likely  to  be  important  with  the  growing  use  of  MBSE 
capability  models  in  Defence 
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7.  Enhancing  the  Clarity  of  Low  Level  Decisions  on  the 
Goals  of  Large  Complex  Projects 


Robert  Dow,  Lyn  Dow,  LCDR  Kim  Baddams  and  David  Kershaw 
Maritime  Operations  Division,  DSTO 


Abstract 

The  aim  of  the  work  is  to  examine  the  possibility  of  developing  a  tool  to  track,  monitor  and 
predict  large  complex  system  development  by  enhancing  the  clarity  of  how  decisions  at  lower 
levels  impact  on  the  goals  of  the  project.  The  approach  uses  Maritime  Operations  Division's 
(MOD)  established  ability  in  combat  system  performance  modelling  using  MBSE  and  attempts 
to  connect  that  level  to  Operational  Capabilities  and  hence  Strategy. 

The  paper  leverages  off  MBSE  tool  capabilities,  developments  such  as  the  Whole  of  System 
Architecture  Framework  (WSAF)  and  research  approaches  such  as  the  Aligned  Process  Model 
(APM).  The  large  complex  project  examined  in  this  experiment  is  the  Future  Submarine 
project  due  to  the  authors'  experience  with  the  project,  however  any  other  large  complex 
project  would  have  been  equally  viable  for  the  experiment. 
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Camouflage  (1974-1976),  and  Electronics  (1978-1983).  Returning  to  work  in  1989,  Lyn 
provided  LAN  network,  computer  and  executive  support  in  Maritime  Operations  Division. 
She  moved  to  MOD,  DSTO-E,  Adelaide  in  1998  where  she  has  worked  on  MBSE  in  support  of 
combat  systems  for  surface  combatants.  Lyn  Dow  currently  works  on  MBSE  for  Maritime 
Warfare  Operations  Group  of  the  Surface  Ship  Operations  Branch,  Maritime  Operations 
Division,  DSTO-E. 
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Kim  Baddams  served  in  the  Royal  Australian  Navy  from  1973  to  1998,  qualifying  as  a  fighter 
pilot.  Air  Warfare  Instructor,  and  Principal  Warfare  Officer  specialising  in  anti-submarine 
warfare.  He  held  staff  positions  in  the  Naval  Warfare  Branch  of  Navy  Office,  where  he  was 
the  inaugural  Director  Above  and  Underwater  Warfare,  and  in  the  Maritime  Development 
branch  of  Defence  Capability  Development.  Since  leaving  full  time  service  he  has  worked  as  a 
Naval  Reserve  in  support  of  Navy  tasks  at  the  Defence  Science  and  Technology  Organisation, 
including  considerable  involvement  with  Model  Based  System  Engineering.  His  qualifications 
include  a  Diploma  of  Maritime  Studies  and  a  Graduate  Diploma  of  Applied  Science. 

David  Kershaw  started  in  Defence  as  a  Cadet  Engineer  with  Navy  Material  in  1987  and 
transferred  to  DSTO  in  1989.  He  holds  a  B.Sc(Hons)  in  Physics,  a  B.E  in  Electrical  and 
Computer  Systems  Engineering  and  a  PhD  in  Tracking  Systems.  Positions  held  within  DSTO 
have  included  Head  of  Torpedoes  &  Torpedo  Defence  Group  (1999  through  to  2002),  Navy 
Scientific  Adviser  (2003-04),  Air  Warfare  Destroyer  S&T  Adviser  (2005-06),  Acting  Research 
Leader  in  Surface  Ship  Operations  (Sept  2006-March  07),  Head  Torpedo  Systems  Group  (2007- 
2010),  and  Head  Submarine  Combat  Systems  Group  (2010-2012).  David  was  appointed  as  the 
Research  Leader  Submarine  Systems  and  SEA  1000  (Future  Submarine)  S&T  Adviser  in  early 
2012. 
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The  Challenge 

To  support  the  Decision  Maker,  we  want  to  look 
at  the  possibility  of  developing  a  tool  to 
monitor  large  complex  system  development 
by  enhancing  the  clarity  of  how  decisions  at 
lower  levels  impact  on  the  goals  of  the 
project. 


The  V-model  of  the  Systems  Engineering  Process 


_  _  Operation 
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■  Validation 

Project  \  Requirements  System 

Definition'  and  Verification 
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Architecture 
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Image  extracted  from  Clarus  Concept  of  Operations.  Publication  No.  FHWA-JPO -05-072,  Federal  Highway  Administration  (FHWA),  2005 
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STANDARD  SYSTEM  ENGINEERING  ‘V’  DIAGRAM 


Goals  of  the  Project  ■♦Top  Level  Requirements 
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Section  3,  Systems  Engineering  for  Intelligent  Transportation  Systems,  US  Dept  of  Transportation,  2007 
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Section  3,  Systems  Engineering  for  Intelligent  Transportation  Systems,  US  Dept  of  Transportation,  2007 

When  did  this  happen?  Was  this  a  conscious  decision? 
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Whole-of-System  Analytical  Framework 


WSAF  Model,  K.  Robinson,  W.  Power,  D.  Tramoundanis,  et  al,  WSD,  David  Harvey,  Paul  Logan,  2012 
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Capability  Development  Life  Cycle  -  Responsibilities 
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Figure  1-2:  Capability  Systems  Life  Cycle  -  Responsibilities 

Defence  Capability  Development  Handbook,  Commonwealth  of  Australia,  201 1 


Risk 

Increasing 


The  Challenge 


Three  reasons  why  this  could  get  difficult 

1 .  Developing  a  tool 

2.  Applied  to  large  complex  system  development 

3.  Attempts  to  enhance  the  clarity  of  how  decisions  at 
lower  levels  impact  on  the  goals  of  the  project. 
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Rationale  for  the  Proposed  Tool 

Requirement:  Quantify  how  low  level  decisions  impact  on  the 
goals  of  the  Project. 

When:  During  acquisition  phase  of  Capability  Development 
Lifecycle. 

Why  Not  Done  Now:  complexity,  cost  and  delay. 

DSTO  advice  needs  to  be  timely,  accurate  and  independent 


Tool  Requirements 

1 .  Fast  and  automated,  1  week  turnaround  for 
advice, 

2.  Run  with  a  minimum  of  manual  effort, 

3.  Works  across  the  entire  MBSE  Project  database 

4.  Deliver  results  in  formats  readily  understood  by 
decision  makers 

5.  Staffing  limited  for  tool  development  and 
application 
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Approach  to  Enhancing  the  Clarity  of  Low  Level 
Decisions  on  the  Goals  of  Large  Complex  Projects 

1 .  Project  Goals  measured  by  submarine’s  ability  to  meet 
Top  Level  Requirements. 

2.  Achievement  of  Top  Level  Requirements  tested  by 
submarine  behaviour  within  agreed  defined  scenarios  and 
vignettes. 

3.  Submarine  behaviour  captured  by  executable  functional 
chains  containing  probability  distributions  and  analytical 
expressions. 

4.  Therefore  measuring  whether  Project  Goals  are  being 
met  can  be  tested  by  executing  submarine  functional 
chains  within  scenarios  and  vignettes  defined  by  the  Top 
Level  Requirements. 


Approach  Informed  by  Work  in  Other  Types  of 

Warfare 

1 .  Mine  Warfare  Command  Tactical  Decision  Aides 
Calculated  effect  of  low  level  changes  on  MCM  Task 
Group  Operations.  Used  Monte  Carlo  simulations, 
analytical  expressions,  and  probability  theory. 

Must  be  calculated  every  task  cycle. 

2.  Maritime  Air  Defence  Combat  System  Performance 
Prediction  using  MBSE. 

Calculation  time  twelve  hours  once  models  built. 
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White  Paper  Strategic  Roles  of  FSM 


DEFENCE  WHITE  PAPER  2009: 

Chapter  9  p70 

The  Future  Submarine  will  be  capable  of  a  range  of  tasks 
such  as; 

1 .  Anti-ship  warfare; 

2.  Anti-submarine  warfare; 

3.  Strategic  strike; 

4.  Mine  detection  and  mine-laying  operations; 

5.  Intelligence  collection; 

6.  Supporting  special  forces  (including  infiltration  and 

exfiltration  missions); 

7.  Getting  battlespace  data  in  support  of  operations. 


Impact  of  High  Level  Function  Failure  on  Project  Goals 
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Sub.  Tasks  -  Defence  White  Paper  2009 

ASuW  Anti-Ship  Warfare 

ASW  Anti-Submarine  Warfare 
SS  Strategic  Strike 

MW  Mine  Warfare 

Intel  Intelligence  Collection 

BD  Battlespace  Data 
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Tool  Implementation  -  a  possible  approach 

1.  One  complete  high  level  function  failure  is  not  likely 

2.  Reality  is  marginal  performance  changes  in  some 
functions 

3.  Approach  for  tool  construction:  functional  chains 
executing  scenarios  and  vignettes  with  MBSE 

4.  Functions  incorporate  external  information:  analytic 
expressions,  tables,  graphs,  probability  distributions 
etc. 

5.  MBSE  Model  execution  tightly  connected  to 
Operational  Requirements,  Architecture  and  System 
Engineering  database. 

•  Removes  translation  errors  between  models 

•  Enables  cross  referencing  within  MBSE  database 


Illustration  of  Designed,  Marginal  and 
Failed  Functional  Behaviour 


FI  F2  F3  F4  F5  FI  F2  F3  F4  F5  FI  F2  F3  F4  F5 


Designed  functional 
performance 

■  Required  parameter  values 


Marginal  functional 
performance 


Failed  functional 
performance 
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Mine  Warfare  Modelling  -  Levels  of  Abstraction 


Level 

Type  of  model 

Characteristics  of  model 

Mine-target  sweep 
interaction,  MH  Sonar, 
single  asset  against 
single  mine  type 

Detailed  physics 
(magnetic  acoustic 
sweep,  sonar  hunt) 
using  MC  simulation 

Large,  detailed  taking  weeks  to 
provide  results  as  cross  channel 
profile  MoP’s 

Single  Asset,  Single 
Pass,  multiple  mine 
type,  sweep  or  hunt 

Calculation  of  single 
pass  for  a  single 
asset  against 
multiple  mine 
threats  MoP 

Equation  combining  single  pass 
cross  channel  MoP  to  multiple 
mine  clearance  cross  channel  MoP 

Single  asset,  multiple 
pass,  sweep  or  hunt 

Calculation  of 
multiple  pass,  single 
asset  against 
multiple  threats  MoP 

Complex  equation  transforming 
single  pass  MoP  to  a  single  asset, 
multiple  pass  MoP  (Clearance 
plot) 

Multiple  Asset, 
multiple  pass 
combined  hunting  and 
sweeping 

Calculation  of 
combined  clearance 
for  hunting  and 
sweeping  assets 

Complex  equation  working  from 
a  plot  combining  achieved 
Clearance  from  single  assets  MoP 
to  multiple  assets  Clearance  Level 
(Combined  Clearance  MoP) 

Correlate  mines 
removed  plot  with 
Clearance  plot  to 
provide  MoE  for  threat 
to  transitor 

Calculation  of  mines 
remaining  and 
threat  to  transitor 

Simple  (but  very  clever) 
calculation  of  MoE 

Calculation 
Done  within 
12  hour 
Tasking 
Cycle 


Submarine  Warfare  Modelling  -  Levels  of  Abstraction 


Level 


Basic  Functions:  sensors, 
weapons,  information 
management,  platform 

models _ 

CS  functions:  Detection, 
TMA,  Targeting,  SINS  POE, 


Target  engagement 


Multiple  Target 
engagement 


Task  (Described  in  DoDAF 
CORE.  Application  should 
model  defined  scenarios 
with  sufficient  accuracy) 


■I 


Type  of  Model 


Detailed  physics  models, 
Integrated  Platform  System 
Model 

Single  sub-function 
performance  model  in  CORE 
including  effects  such  as 
probability  distributions  and 
computing  resources 

CS  model  execution  (prior 
example  ANZAC  Extant) 


CS  model  of  multiple  Target 
engagement  (prior  example 
I  ANZAC  ASMD) 


Defined  scenario  DoDAF 
CORE  Operational  model 


Characteristics  of  Model 


Large,  detailed,  major  effort 
to  maintain,  slow  to  generate 
results  (months)  possibly  as 
probability  or  sub-function 
EFFBD  execution  with 
internal  calculation.  A 
probability  distribution  or  a 
sub-function  model  could  be 
used  in  the  next  level. 

EFFBD  execution  with 
internal  calculation.  Output: 
probability  distribution  or  a 
sub-function  model  could  be 
used  in  the  next  level. 

EFFBD  execution  with 
internal  calculation.  Output: 
probability  distribution  or  a 
sub-function  model  could  be 
used  in  the  next  level. 

EFFBD  execution  with 
internal  calculation:  Output 
result  in  format  suitable  for 
Decision  Makers  i.e. 
Probability /Traffic  Light 
colour 


Calculation 
Done  within 
One  week 
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Layout  of  the  Modelling  Layers  Contained  within 
‘Clarity’  Tool  &  How  it  Can  Support  Timely  Decisions 

1 .  Detailed  models  from: 

The  Integrated  Platform  System  Model  (MPD,  DSTO)  for  whole  of 
submarine  margins 

Physics  and  engineering  for  sensors  and  weapons 
With  Prior  modelling  calculation  time  -  weeks 

2.  Executable  models  in  MBSE  (CORE). 

Use  'distilled'  information  from  above  within  MBSE  Functions 
Submarine  functional  chain  execution  in  scenarios  &  vignettes 
Informed  by  Operations  Research 

Parametric  analysis  (minimal)  -  changes  in  few  low  level  functions 
Computation  time  -  days 

3.  Final  layout  of  results  in  formats  for  decision  makers 

May  require  information  display  tools  outside  MBSE  (CORE) 


Challenges  for  Tool  Development 

1.  Inputting  the  FSM  Project  into  MBSE 

1.1  Helpful: 

Capability  Development  using  WSAF  (MBSE  CORE) 

Should  have  two  -  five  years 

1.2  Difficult: 

Low  level  changes  to  functions  need  detailed  implementation 
-  may  be  difficult  within  Project  response  times 

2.  Moving  between  operations  and  engineering  understanding  of 

parameter  values  during  Project? 
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Engineering  vs  Operations  Understanding  of 
Parameter  Values 

1. Operational  performance  measured  from  operational/exercise 
analysis  vs. 

2.Engineering  Performance  calculated  from  physics  and 
engineering  signal  processing 


Probability 
of  Detection 


Range  from  Sensor 


Is  it  worth  doing? 

How  else  might  it  be  done? 
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8.  Employing  Concept  Definition  Techniques  to  Deliver 
Value  on  the  RAN  Air  Warfare  Destroyer  Program 


Steven  J.  Saunders 
Raytheon  Australia 


Abstract 

Modern,  complex  development  systems  pose  risks  in  defining  the  right  system  solution, 
building/  integrating/  delivering  the  capability  and  sustaining  the  capability  through  the 
complete  lifecycle  of  that  system.  Major  defence  acquisition  programs,  like  the  SEA  4000  Royal 
Australian  Navy  (RAN)  Air  Warfare  Destroyer  (AWD)  Program  are  no  different.  This 
presentation  describes  concept  engineering  processes  employed  on  the  AWD  combat  system 
during  the  capability  definition  stage  of  the  Program. 

Concept  definition  is  a  critical  activity  of  any  major  system  development,  requiring  a  balanced 
approach  to  multiple  stakeholder  considerations.  The  AWD  Program  has  met  this  challenge 
by  employing  a  collaborative  team  approach,  early  systems  architecting  and  judicious  use  of 
Model  Based  Systems  Engineering  (MBSE).  In  this  presentation,  it  is  shown  how  Operational 
Activity  models  and  supporting  architectural  views  have  been  successfully  used  to 
communicate  the  system  capability  with  the  AWD  capability  sponsors.  As  the  program  has 
progressed,  this  MBSE  environment  has  been  progressively  expanded  to  include  additional 
SysML  system  composition  and  system  behaviour  model  elements  to  support  the  system 
definition  activities.  A  significant  "by-product"  of  the  system  model  has  been  the  ability  to 
identify,  quantify  and  perform  technical  risk  assessment  on  all  system  interfaces  in  order  to 
provide  a  lead  indicator  of  the  cumulative  integration  risk  to  the  program.  Using  this 
information,  the  architecture  has  been  incrementally  refined  during  concept  definition  in 
order  to  ensure  the  program  integration  risk  has  been  minimized  whilst  ensuring  other  key 
stakeholder  values  have  been  satisfied. 

Key  lessons  from  this  presentation  demonstrate  the  applicability  of  MBSE  techniques  in 
complex/ large  programs  and  the  reality  that  theoretical  application  of  MBSE  must  be  tailored 
and  augmented  with  other  visualisations  and  tools  to  communicate  with  the  variety  of 
stakeholders  engaged  in  the  concept  definition  phase  of  the  program. 

Presenter  Biography 

Steve  Saunders,  FIEAust  CPEng,  is  an  Engineering  Fellow  for  Raytheon  Australia.  He 
received  his  Bachelor  of  Electrical  Engineering  from  the  University  of  Technology  Sydney 
(UTS)  with  first  class  Honors  in  1990.  He  has  worked  with  Rockwell  International,  Boeing 
Australia  and  now  Raytheon  Australia  on  Australian  Defence  projects  in  various  Systems 
Engineering  Management,  Requirements  Development,  Architecture,  Design  and  Test  roles. 
He  is  a  Raytheon  certified  architect  having  completed  the  Raytheon  Certified  Architect 
Program  in  2005. 
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Steve  has  been  involved  in  the  Royal  Australian  Navy's  Air  Warfare  Destroyer  Program  since 
2005  as  the  Combat  System  Chief  Architect  working  in  phase  2  of  the  Program  to  establish  the 
Combat  System  architecture.  He  is  now  the  AWD  Combat  System  Chief  Engineer  and  Combat 
System  design  authority. 

Steve  has  written  numerous  articles  on  Systems  Engineering  and  System  architecting  and  has 
an  interest  in  improving  System  Engineering  and  System  Architecting  maturity  and  the  agility 
of  Systems  Engineering  to  support  the  rapidly  evolving  technology  environment  and 
complexity  within  the  defence  industry. 
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Agenda 


Raytheon 

Australia 


>  What  is  the  Problem  with  Systems  Engineering  Today? 

>  How  is  Concept  Engineering  Used  on  the  AWD  Program 

■  Background 

■  M  BSE  Approach 

■  Useful  ‘by-products’ 

>  Lessons  from  the  AWD  Program 

>  Key  Take-Aways 


>  Questions 


DSTO  MBSE  Symposium,  27-28  Nov  2012, 
DSTQ  Edinburgh,  SA _ 


The  Term  Concept  Engineering  is  used  to  define  the  activities  carried  out  in  the 

"Concept  Definition"  phase  of  a  Program 
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What  is  the  Problem  with  Systems  Engineering  (SE)  Today? 


DSTO  MBSE  Symposium,  27-28  Nov  2012, 
DSTO  Edinburgh,  SA 
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What  is  the  Problem  with  SE  Today? 


Raytheon 

Australia 


>  The  ‘Easy’  Phases  -  Systems  Requirement  to  Delivery 


System 

Specification 


DSTO  MBSE  Symposium,  27-28  Nov  2012, 
DSTO  Edinburgh,  SA 


Systems  Engineering  Processes  are 
mature  and  well  understood 


Transforms  Requirements  to  verified 
System 

MBSE  or  Document  Centric  or  Hybrid 
approaches  applicable 

Reasonable  tool  support 


But... 
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What  is  the  Problem  with  SE  Today? 


Raytheon 

Australia 


>  Assertion  ->  There  is  a  Problem! 

■  How  are  the  right  requirements  defined? 

.  Will  the  realisation  of  the  requirements  be  affordable? 

♦  Can  the  requirements  be  verified? 

.  Realisable  in  available  technology? 

♦  Considers  full  lifecycle?^ 

.  Meets  the  need? 


System 


Concept  Definition  (Concept  Engineering) 
Helps  Ensure  the  Right  Requirements  are  Specified 


DSTO  MBSE  Symposium,  27-28  Nov  2012, 
IdSTQ  Edinburgh,  SA  
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Raytheon 

What  is  the  Problem  with  SE  Today?  Australia 

>  Why  may  Concept  Definition  Phase  be  Skipped  or 
Superficially  Addressed?  --  It  is  HARD! 

•  SOFT  Engineering 

•  Business  Language, 

•  Fuzzy  Criteria,  | 

•  Best  fit  rather  than  e 

o 

exact  answers  » 

•  It  is  COMPLEX... 

•  Components 

•  Systems 

•  Enterprises 

•  People  /  Processes 

•  Sociological 

•  Political 

•  Environmental 


Increasing  Connectivity  /  Relationships 


UNCLASSIFIED 


77 


DSTO-GD-0734 


UNCLASSIFIED 


How  is  Concept  Engineering  used  on  AWD  - 

Background 


Raytheon 

Australia 


The  Royal  Australian  Navy’s  (RAN)  Air  Warfare  Destroyer  (AWD)  Program  is 
employing  a  mix  of  strategies  and  contracting  mechanisms  to  deliver  a  new  major 
surface  combatant  to  the  RAN  within  an  aggressive  timeframe 
8  Years  to...  I  /  J 

■  Select  Equipment  and  Complete  the  Design  J  \  /  \  I  ^  \  ^ 

■  Build  Shore  Facilities  &  Integration  Facilities 

■  Build  the  Shipyard 

■  Build  the  Lead  Ship 

■  Integrate  and  deliver  the  Capability 


>  The  AWD  Program 

■  has  met  major  Program  milestones, 

■  has  passed  System  CDR, 

■  keel  Layed  -  Future  Destroyer  HOBART 

■  ship  blocks  for  all  3  ships  are  in  production, 

■  has  excellent  customer  relationships, 

■  is  scheduled  to  deliver  the  required  capability  to  the  RAN  in  201 6 
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How  is  Concept  Engineering  used  on  AWD  -  Raytheon 

A  new  Way  of  Doing  Business_ Australia 

>  RAN  Requires  a  new  Capability  “No  Later  Than”  with  Set  Funding 

>  Schedule/Cost  Constraints  Require... 

■  Collaboration  between  the  Customer  and  the  Mission  System  Integrator  (MSI) 

■  Stakeholders  to  Work  Cooperatively  for  Improved  Program  Performance  and  Agility 

■  Rapid  Development  of  the  Capability  (MOTS/COTS  vs  New  Development) 


>  Ensuring  the  System  is  Supportable  for  the  Life  of  Type 


Customer  /  MSI 
Collaboration 


Contracting 
Considerations 


*^kCc 

^*MOTS/C< 


LA  Architecture 
Considerations 


j  MOTS/COTS 
Design  Strategy 


Concept  Engineering 
concurrently  focused  on 
multipl&'considerations 
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How  is  Concept  Engineering  used  on  AWD 

-Strategy:  MBSE  Approach 


Raytheon 

Australia 


Operational  Analysis 
Derive  OV-5b 
Determine  FIC,  MOE 


Operational  Vignettes 

Cost  Considerations  CAIV 
Capability  Evolution  SV-8 
Integration  Strategy 
Lifecycle  Considerations  StdV-2- 
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Analyse,  Refine,  Iterate 
In  MBSE  Environment 


SV-5a 


UNCLASSIFIED 
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How  is  Concept  Engineering  used  on  AWD  -  Raytheon 

-  Strategy:  MBSE  Approach 


>  Analyse  using  language  of 
Capability  Development  Group 

>  Simplify  Complexity  using 
Architecting  Practices 

■  Model  with  Suitable  Tools 

>  Analyse  and  Balance  Considerations 

■  Delivered  Capability 

■  Regulatory  Compliance 

■  Conformance  to  budget  and  schedule 

■  Risk  to  delivery 

■  System  Evolution 

■  Technology  Evolution 


>  Iterate 


Employ  System  Architecting  to  Analyse  using  Customer  Language 
Hide  Complexity  ->  Allow  Balanced  Decisions 
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How  is  Concept  Engineering  used  on  AWD  - 

MBSE  Architectural  Model 


Raytheon 

Australia 


Operational  /  Regulatory  Viewpoint 

Visualisations 


Use  Cases 


Operational 

Vignettes 


?!  L>-- 
Cr  1 , 


■g  -b  -**»• 

^  r~*-  -bb  tii  3 


Technical 
Integrity  Risk 


(Operational)  Activity 
Diagrams 


;  T; 


^  v 

•# 


System  Activity 


-£££tt- 


Block  Definition 
Internal  Block  Diagrams 

MBSE 

Environment 
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£1 

_ 

:i 

IS 

! 

• 

Functional HierarchJ  SystGm  Definition 
ca  ™PP5 1  Views 


Data  Models 


State 

Machines 


j CL 


Sequence  Diagrams  Interface  Report  integration  and  V&V 


-  IRL  Ranking 


Planning 
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How  is  Concept  Engineering  used  on  AWD  -  Raytheon 

Apply  MBSE  Where  Appropriate 


Language  of  the  Business  /  Stakeholders 


Operational  /  Regulatory  Viewpoint 

Visualisations 


Operational 

Vignettes 


Use  Cases 

* 


K' 


(Operational)  Activity 
Diagrams 


oint 

sualisations 

"  -  .... 

Technical 
Integrity  Risk 


System  Activity 
Diagrams 


Functional  Hierarchy!  System  Definition 

Views 


w. 


* 

.  *****  ' 


Block  Definition 
Internal  Block  Diagrams 

MBSE 

Environment 


State 

Machines 


Sequence  Diagrams  Interface  Report  integration  and  V&V 
-  IRL  Ranking  Planning _ 


Language  of  Engineers 
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How  is  Concept  Engineering  used  on  AWD  - 

By-Product:  Minimise  Integration  Risk 


Raytheon 

Australia 


>  Model  contains  all  interfaces 

■  Assign  Interface  risks  (Interface  Technology  Level  &  Complexity) 

■  Assess  Risk  Profile 

■  Tune  the  Architecture 

■  Minimise  Integration  Risk 


Interface  Risk  Profile  •  Program  Trend 


//////////////// / / / / / / / 


■  1 .  Haw  Ilf  In  aithar  OTS  Component 
7.  Exttong  InMrtaca  -  VanIWd  0.  Human  in  th«  Loop 
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Raytheon 

Lessons  From  the  AWD  Program 

■  Employ  System  Architecting  early 

■  Able  to  model  capability  using  SYSML  ->  Effective  CDG  Interactions 

■  Simplified  complexity  enables  effective  decision  process 

•  Employment  of  CAIV 

.  Considerations  for  System  Evolution 

•  Considerations  of  Technology  Evolution 

•  Integration  of  Integration  Strategies 

■  Full  Employment  of  all  SYSML  elements  not  required  (or  desired) 

■  IP  /  ITAR  Restrictions  Constrains  Completeness  of  a  single  model 

■  Supports  Integration  Risk  Assessment 

■  MBSE  helps  highlight  compatibility  &  terminology  issues 


Up-Front  Effort  in  Concept  Engineered 
increases  confidence  the  capability  can  be  developed  and  delivered 
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Raytheon 

Key  Take  Aways_ Australia 

>  Do  not  start  with  Requirements!!  Define  the  Problem 

>  Undertake  Concept  Definition  in  the  Customer/User  Language 

>  Hide  Complexity  ->  Complexity  is  an  enemy 

>  Iterate  the  reference  architecture  /  consider  broad  business 
considerations 

>  Balance  near  term  (Delivery)  as  well  as  Sustainment  needs 

>  Apply  MBSE  concepts  in  a  targeted  manner  rather  than  theoretical 

■  OV-5b  (Activity  Model)  most  beneficial  in  concept  definition  phase 


Do  not  skip  Concept  Engineering  Activities! 
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Questions 


Raytheon 

Australia 


Page  18 


AWD  MBSE  Model  “Factoids” 

Data  as  at  Oct  2012 


49 

Operational  Vignettes 

119 

Use  Cases 

281 

Segment  Level  Functions 

787 

Activities 

948 

Diagrams 

42,222 

Elements 

16,069 

Connections 

106 

Blocks  in  Logical  Model 

953 

Blocks  in  Physical  Model 

432 

Interface  Messages 

jo  i : 
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Glossary 

Raytheon 

Australia 

>  AWD 

Air  Warfare  Destroyer 

>  CAIV 

Cost  as  an  Independent  Variable 

>  CDG 

Capability  Development  Group 

>  CDR 

Critical  Design  Review 

>  COTS 

Commercial  Off  the  Shelf 

>  DoDAF 

Department  of  Defense  Architecture  Framework,  v2.0,  28  May  2009 

>  IP 

Intellectual  Property 

>  IRL 

Interface  Readiness  Level 

>  ITAR 

International  Traffic  in  Arms  Regulation 

>  MBSE 

Model  Based  Systems  Engineering 

>  MOTS 

Military  Off  the  Shelf 

>  MSI 

Mission  Systems  Integrator 

>  OV-1 

Operational  Concept  Graphic  (DoDAF  v2.0) 

>  OV-5b 

Operational  Activity  Model  (DoDAF  v2.0) 

>  RAN 

Royal  Australian  Navy 

>  SE 

Systems  Engineering 

>  SV^t 

Systems  Functionality  Description  (DoDAF  v2.0) 

>  SV-5a 

Operational  Activity  to  Systems  Traceability  Matrix  (DoDAF  v2.0) 

>  SV-8 

Systems  Evolution  Description  (DoDAF) 

>  SysML 

Systems  Modeling  Language 

>  StdV-2 

Standards  Forecast  (DoDAF  v2.0) 
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9.  WORKSHOP  1:  What  is  a  'Capability  System  Model'? 


Dr  Michael  Ryan 
University  of  New  South  Wales 


Abstract 

In  the  current  Defence  acquisition  system,  the  Capability  System  is  described  principally  in 
the  text-based  Capability  Definition  Documents  (CDD)  set  of  documents,  which  are  provided 
to  potential  prime  contractors  through  a  formal  tendering  process.  Tenderers  are  required  to 
digest  the  CDD  in  order  to  propose  system-level  solutions  to  the  Materiel  System.  Tendered 
solutions  are  assessed  by  the  customer  for  compliance  with  the  CDD  (as  well  as  with  other 
terms  and  conditions  of  the  tender).  This  text-based  process  is  often  perceived  as  inefficient, 
with  a  high  likelihood  of  errors.  One  way  to  overcome  these  shortcomings  would  be  to  use  an 
MBSE  approach  to  pass  Capability  System  models  across  the  contractual  interface  and 
integrate  them  to  the  Materiel  System  models  included  in  the  tendered  solutions. 

In  an  MBSE-supported  system  acquisition,  however,  the  Materiel  System  is  treated  as  a  black 
box  with  its  internal  functions  being  subsequently  defined  by  the  tenderers  in  the  solution 
space  (presumably  in  a  different  way  by  each  of  the  tenderers).  To  that  end,  the  Capability 
System  Models  developed  by  the  customer  would  treat  the  Materiel  System  as  a  single  entity 
in  order  to  show  how  it  would  be  operated  and  supported  in  the  operational  environment. 
These  Capability  System  Models  would  then  be  passed  across  the  acquisition  boundary  so 
that  tenderers  can  show  how  their  tendered  Materiel  System  model  performs  in  the  context  of 
the  Capability  System  Model. 

In  order  to  be  in  position  to  use  a  Capability  System  Model  as  part  of  the  acquisition  of  a 
Materiel  System,  the  customer  must  therefore  undertake  considerable  modelling  of  the  wider 
context  of  the  Capability  System  as  well  as  of  the  relevant  Fundamental  Inputs  to  Capability 
(FIC)4  elements. 

This  workshop  examines  how  a  Capability  Systems  Model  could  be  used  to  replace  the 
existing  text-based  content  of  the  CDD  documents.  In  particular: 

•  The  workshop  will  begin  with  an  examination  of  the  existing  CDD  in  order  to  identify 
which  elements  of  the  existing  documents  can  be  replaced  by  the  Capability  System 
Model  and  which  elements  would  need  to  remain  text-based.  Relevant  documents 
include  the  Operational  Concept  Document  (OCD)  and  the  Function  and  Performance 
Specification  (FPS). 

•  Attention  will  then  turn  to  identifying  the  degree  to  which  the  customer's  business 
processes  be  modelled  in  order  to  provide  an  appropriate  level  of  abstraction  for  the 
Capability  System  Model,  so  that  it  is  suitable  to  be  used  as  the  major  artefact  to  cross 
the  acquisition  boundary. 


4  The  FIC  is  the  standard  list  for  consideration  of  what  is  required  to  generate  Defence  capability, 
comprising  organisation ,  personnel ,  collective  training,  major  systems ,  supplies ,  facilities ,  support ,  and 
command  &  management. 
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Specifically,  the  workshop  will  address  the  following  three  questions: 

Question  1:  What  information  and  processes  currently  described  in  text-based  systems 
acquisition  (TBSA)  (i.e.  in  the  OCD  and  FPS)  would  still  be  required  to  be  included  in  some 
way  in  the  MODEL  which  is  the  basis  of  model-based  systems  acquisition  (MBS A)? 

Question  2:  How  can  each  information/ process  be  modelled  in  MBS  A,  and  how  would  that 
be  different  to  TBSA? 

Question  3:  What  processes/ information  would  be  modelled  in  MBSA  that  do  not  exist  in 
TBSA? 

Facilitator  Biography 

Dr  Michael  John  (Mike)  Ryan  is  a  Senior  Lecturer  with  the  School  of  Engineering  and 
Information  Technology,  University  of  New  South  Wales,  at  Canberra.  He  holds  Bachelor, 
Masters  and  Doctor  of  Philosophy  degrees  in  electrical  engineering  as  well  as  a  Graduate 
Diploma  in  Management  Studies.  In  addition,  he  has  completed  two  years  formal  project 
management  training  in  the  United  Kingdom.  For  the  first  seventeen  years  of  his  career  he 
held  a  number  of  communications  engineering,  systems  engineering,  project  management, 
and  management  positions  in  the  Australian  Army.  Since  joining  UNSW,  he  has  become  an 
internationally  recognised  expert  in  systems  engineering  and  requirements  engineering,  and 
has  made  a  number  of  important  contributions  to  the  field. 

Dr  Ryan  regularly  consults  in  the  fields  of  systems  engineering,  requirements  engineering, 
communications  and  information  systems  architectures,  project  management,  and  technology 
management  including  work  for  the  2004  Athens  Olympic  Games,  the  Department  of  Defence, 
other  government  departments,  defence  industry,  and  other  industry. 

Dr  Ryan  conducts  courses  in  systems  engineering  and  requirements  engineering  as  well  as  in 
the  more-focused  application  in  Defence  acquisition,  particularly  in  the  development  of  the 
capability  development  documents  (CDD)  that  guide  acquisition  in  the  Australian 
Department  of  Defence.  He  is  the  principal  architect  of  the  Master  of  System  Engineering 
program  run  by  the  University  of  New  South  Wales  in  Canberra,  creating  the  program 
structure  and  preparing  the  appropriate  documentation  for  program  approval.  He  also 
developed  three  of  the  four  core  courses  in  that  program  and  is  currently  delivering  two  of  the 
courses  (systems  engineering  and  requirements  engineering). 

He  is  a  Fellow  of  the  Institution  of  Engineers,  Australia;  a  senior  member  of  the  Institute  of 
Electrical  and  Electronic  Engineers;  a  member  of  the  International  Council  on  Systems 
Engineering;  and  a  member  of  the  Systems  Engineering  Society  of  Australia  (in  which  he  also 
serves  on  the  management  committee  as  the  academic  representative  and  the  chair  of  the 
annual  conference).  He  is  currently  the  Chair  of  the  Requirements  Working  Group  in  the 
International  Council  on  Systems  Engineering  (INCOSE). 

Dr  Ryan  is  the  Editor-in-Chief  of  the  international  journal.  Journal  of  Battlefield  Technology ,  and 
is  the  author  or  co-author  of  nine  books  and  three  book  chapters  and  over  100  technical  papers 
and  reports.  He  is  a  principal  author  of  the  Guide  for  Writing  Requirements,  recently  published 
by  INCOSE  and  is  one  of  the  authors  of  the  revised  edition  of  the  INCOSE  Systems  Engineering 
Handbook  (which  is  the  basis  of  accreditation  of  systems  engineers  internationally). 
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Workshop  Presentation  and  Outcomes 


What  is  a  Capability  System  Model? 

•  Question  1 :  Since  text-based  systems  acquisition  (TBSA) 
doesn’t  work,  what  information  and  processes  currently 
described  in  TBSA  (in  the  OCD  and  FPS)  would  still  be 
required  to  be  included  in  some  way  in  the  MODEL  which  is 
the  basis  of  model-based  systems  acquisition  (MBSA)? 

•  Question  2:  How  can  each  information/process  be  modelled 
in  MBSA,  and  how  would  that  be  different  to  TBSA? 

•  Question  3:  What  processes/information  would  be  modelled 
in  MBSA  that  do  not  exist  in  TBSA? 


Systems  Acquisition  in  Defence 
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Major  Artefacts 


Acquisition  Phase 


Conceptual 

Design 

Preliminary 

Design 

Detailed 

Design  and 
Development 

Construction 

and/or 

Production 

Stakeholder 

Requirement 

Document 

(SRD) 


Functional  Baseline 
(System  Specification) 

CONTRACT 


Allocated  Baseline 
(Development  Specification) 


Product  Baseline 
(Product  Specification) 


Operational  Function 

Concept  and 

Document  Performance 

(OCD)  Specification 

(FPS) 

Test  Concept  Document  (TCD) 

Capability  Definition  Documents 
(CDD) 


System 

Specification 

(SS) 


Sub-system 

Specifications 

(SSS) 


OCD  Template 

1 . 

SCOPE 

3.4.2  Scenario  1  -  Scenario  Title 

1.1 

Capability  Identification 

3.4.2. 1  Summary  of  Situation 

1.2 

Document  Purpose  &  Intended  Audience 

3. 4. 2. 2  Summary  of  Military  Response 

1.3 

Justification  for  Capability 

3. 4. 2. 3  Summary  of  Operational  Needs 

1.4 

System  Boundary  and  Acquisition 

3.4.3  Scenario  N  -  Scenario  Title 

Assumptions 

3.5 

Summary  of  Consolidated  Operational 

1.5 

Key  Timeframes  for  Capability 

Needs 

2. 

DEFINITIONS  AND  REFERENCED 

3.6 

Solution-class-independent  Constraints 

DOCUMENTS 

4. 

EXISTING  SYSTEM 

2.1 

Referenced  Documents 

4.1 

Existing  System  Overview 

2.2 

Glossary  of  Terms 

4.2 

Existing  System  Operational  Capability 

3. 

SOLUTION-INDEPENDENT 

Comparison 

CAPABILITY  NEEDS 

4.3 

Existing  System  Internal  Shortcomings 

3.1 

Mission  Overview 

4.4 

Existing  System  Planned  or  Active 

3.2 

Operational  Policies  and  Doctrine 

Upgrades 

3.3 

Capability  System  End-user  classes 

4.5 

Existing  System  Internal  User  classes 

3.4 

Summary  of  Operational  Scenarios 

4.6 

Existing  System  Internal  Functionality 

3.4.1 

Common  Scenario  Attributes 

4.7 

Summary  of  Existing  System  Internal 
Scenarios 

DID-ENG-DEF-  OCD-  V2.0 
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OCD  Template 


5.  SOLUTION-CLASS  DESCRIPTION 

5.1  Materiel  System  Description 

5.2  Mission  System  Architecture 

5.3  Materiel  System  Interfaces 

5.4  Materiel  System  Internal  User  classes 

5.5  Materiel  System  Functionality  and 
Performance 

5.6  Materiel  System  Spt  Concepts  and  Reqts 

5.7  Materiel  System  Constraints 

5.8  Materiel  System  Evolution  &  Tech  F’cast 

5.9  Summary  of  Internal  Scenarios 

5.9.1  Internal  Scenario  1 

5. 9. 1.1  Summary  of  Situation 

5.9.1 .2  Summary  of  Process  Flows 
Interactions 

5. 9. 1.3  Summary  of  System  Reqts 

5.9.2  Internal  Scenario  2  -  Scenario  Title 

5.9.3  Internal  Scenario  N  -  Scenario  Title 


6.  CONSOLIDATED  FUNDAMENTAL 
INPUTS  TO  CAPABILITY (FIC) 
REQUIREMENTS 

6.1  FIC  Related  Guidance 

6.2  Major  Systems  FIC  Element 
Requirements 

6.3  Facilities  and  Training  Areas  FIC 
Element  Requirements 

6.4  Support  FIC  Element  Requirements 

6.5  Supplies  FIC  Element  Requirements 

6.6  Organisation  FIC  Element  Requirements 

6.7  Command  and  Management  FIC 
Element  Requirements 

6.8  Personnel  FIC  Element  Requirements 

6.9  Collective  Training  FIC  Element 
Requirements 

6.10  FIC  Impacts  on  Supporting  Capabilities 

6.1 1  Summary  of  Overall  FIC  Responsibilities 

6.12  FIC  Development  Forecast 


D/D-EA/G-DEF-OCD-  V2.0 


FPS 


•  Specifies  formal  requirements  for  the  System. 

•  Provides  the  basis  for  design  and  qualification  testing  of  the 
system. 

•  Provides  the  vehicle  for  the  capture  of  formal,  verifiable  and 
unambiguous  requirements,  ‘distilled’  from  the  OCD. 

•  Is  intentionally  written  using  formal  language,  with  all 
requirements  in  the  FPS  traceable  to  needs  in  the  OCD. 


CDD  Guide  v2.0 
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FPS  Template 


Section  1  -  Scope 

1.1  -  Identification 

1 .2  -  System  Overview 
1.3-  Document  Overview 
Section  2  -  Appiicabie  Documents 
Section  3  -  Requirements 

3.1  -  Missions 

3.2  -  System  Boundaries  and  Context 

3.3  -  Required  States  and  Modes 

3.4  -  System  Capability  Requirements 

3.5  -  Availability 

3.6  -  Reliability 


3.14  -  Environmental  Impact  Requirements 

3.15  -  Useability  and  Human  Factors 

3.16  -  Security  and  Privacy 

3.17  -Adaptation  Requirements 

3.18  -  Design  and  Implementation 


Constraints 

3.19 -System  Interface  Requirements 
Section  4  -  Precedence  and  Criticaiity  of 


Requirements 
Section  5  -  Verification 
Section  6  -  Requirements  Traceability 
Section  7  -  Notes 


3.7  -  Maintainability 

3.8  -  Deployability 

3.9  -  Transportability 

3.10  -  Environmental  Conditions 

3.11  -  Electromagnetic  Radiation 

3.12 - Architecture,  Growth  and  Expansion 

3.13 - Safety 


Workshop  Outcomes 

©What  is  a  (capability)  model? 

■  An  algorithm  is  a  model 

■  Level  of  abstraction 

■  Conceptual  model  to  executable  model 

■  Non  functional  requirements  /  constraints 

■  Expression  of  knowledge 

■  Behaviour  of  a  system  (including  over  time) 

■  Describes  the  structure  of  the  environment  and  interfaces 

■  Visible  FIC  elements  including  the  support  system 

■  Performance  and  boundaries  of  execution 

■  Describes  the  problem 

■  Captures  the  requirements 

■  Fit-for-purpose  representation  of  the  capability 

■  Structured  and  traceable  information 
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Workshop  Outcomes 

©What  is  the  purpose  of  the  (capability)  model? 

■  Develop  shared  understanding 

■  Enables  /  Documents  decision  making 

■  Knowledge  transfer 

■  To  go  to  contract  /  tender 

■  Communicate  the  capability  of  a  system  to  a  sufficient  level  of 
fidelity  (reduce  risk) 

■  Validation  baseline 

■  Integration  of  knowledge  from  lower  level  models 

■  To  describe  the  relationships  with  the  capability  of  your  other 
systems 
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10.  WORKSHOP  2:  MBSE  Practices  Across  the 
Contractual  Boundary 


Quoc  Do1  and  Jon  Hallett2 

aDefence  Systems  Innovation  Centre  (DSIC)  and  2Deep  Blue  Tech 


Abstract 


Systems  engineering  practice  is  progressively  migrating  to  Model-Based  Systems  Engineering 
(MBSE)  practice  as  evidenced  through  the  contributions  to  the  DSTO  MBSE  Symposium 
(2011),  INCOSE  MBSE  International  Workshop  (2012)  and  ongoing  activities  in  various 
Australian  organisations  such  as  DSTO5,  Deep  Blue  Tech6,  Air  Warfare  Destroyer7,  Aerospace 
Concepts8,  Raytheon9,  and  DSIC10'11.  Furthermore,  MBSE  is  gaining  momentum  within  the 
Australian  Department  of  Defence.  In  particular,  the  SEA  1000,  LAND  400,  and  LAND  19 
(Phase  7)  projects  are  adopting  an  MBSE  approach  for  the  capability  system  definition. 


However,  to  date  MBSE  has  only  been  adopted  on  an  "Ad-hoc"  basis  (aka  "model-supported 
engineering").  In  other  words,  models  are  used  to  support  the  system  engineering  activities  at 
distinct  phases,  rather  than  being  evolved  and  matured  throughout  the  system  lifecycle.  One 
of  the  key  impediments  is  the  reliance  by  all  parties  on  the  use  of  documents  at  the  contractual 
interface  between  the  acquirer  and  the  provider,  as  illustrated  in  Figure  1. 


Acquirer's 
Capability 
Systems  Mode! 


Figure  1:  Contractual  Interface 


As  a  result,  in  the  defence  context, " above-the-line"  (acquirer)  capability  models  are  required  to 
produce  a  Capability  Definition  Document  (CDD)  set  and  other  related  artefacts.  These 


5  Robinson,  K.,  et  al.  Demonstrating  Model-Based  Systems  Engineering  for  Specifying  Complex  Capability ,  in 
Systems  Engineering  Test  and  Evaluation  (SETE)  2010  Adelaide,  Australia 

6  Pearce,  P.,  Model-Based  Systems  Engineering  and  Its  Application  to  Submarine  Design ,  in  Submarine 
Institute  of  Australia  Science,  Technology  and  Engineering  Conference  2011,  Adelaide,  Australia 

7  Mays,  R.,  Deploying  a  SysME  MBSE  Environment  -  Lessons  Learned  from  the  SEA  4000  -  Air  Warfare 
Destroyer  Program ,  in  DSTO  MBSE  Symposium  2011,  Adelaide,  Australia 

8  Harvey,  D.,  et  al..  Document  the  Model ,  Don '  t  Model  the  Document,  in  INCOSE  International  Symposium 
2012,  Rome,  Italy 

9  Saunders,  S.,  Does  a  Model  Based  Systems  Engineering  Approach  Provide  Real  Program  Savings?  -  Lessons 
Learnt ,  in  DSTO  MBSE  Symposium  2011,  Adelaide,  Australia 

10  Do,  Q.,  et  al..  Requirements  for  a  Metamodel  to  Facilitate  Knowledge  Sharing  between  Project  Stakeholders ,  in 
10th  Annual  Conference  on  Systems  Engineering  Research  (CSER  2012)2012,  Missouri,  US 

11  Do,  Q.  and  S.  Cook,  An  MBSE  Case  Study  and  Research  Challenges ,  in  22nd  Annual  International 
Symposium  of  INCOSE2012,  INCOSE,  Rome,  Italy 
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documents  are  then  provided  to  potential  prime  contractors  (providers)  who  then  interrogate 
them  to  produce  their  own  systems  model.  This  is  an  inefficient  process  and  there  is  a  high 
likelihood  of  errors  and  unwanted  artefacts  being  introduced  into  the  process. 

One  solution  would  be  to  pass  the  capability  system  models  through  the  contractual  interface 
and  integrate  them  to  the  provider's  system  solution  model.  In  order  to  address  this  issue,  the 
workshop  aims  to  discuss  and  surface  the  key  issues  and  challenges  inherent  in  utilising  a 
single  MBSE  representation  in  a  competitive  tender  environment. 

The  workshop  discussion  will  be  limited  to  the  Request  For  Tender  (RFT)  defence  contracting 
model  and  will  be  focussed  on  the  following  areas  (but  not  limited  to): 

1.  What  classes  of  information  in  the  Acquirer's  Capability  System  Model  should 
be  disclosed  to  the  Provider? 

2.  What  classes  of  information  in  the  Provider's  System  Solution  Model  should  be 
disclosed  to  the  Acquirer? 

3.  How  should  the  two  models  be  interfaced? 

4.  Metamodels  that  could  underpin  items  1-3 

5.  Model-based  tender  evaluation  by  the  acquirer 

6.  Model-based  RFT  evaluation  by  the  provider 

7.  Legal  framework  and  IP  issues. 

Facilitator  Biographies 

Dr  Quoc  Do  is  currently  a  Research  Lead  -  MBSE,  at  the  Defence  Systems  Innovation  Centre 
(DSIC),  and  a  Research  Fellow  at  the  Defence  and  Systems  Institute  (DASI),  University  of 
South  Australia.  He  completed  his  BEng,  MEng  and  PhD  all  at  the  University  of  South 
Australia.  His  research  interests  are  in  the  areas:  1)  systems  engineering,  including  systems 
integration  of  COTS/ MOTS  components,  Model-Based  Systems  Engineering  (MBSE),  systems 
engineering  of  autonomous  systems,  and  systems  of  systems;  and  2)  domain-specific 
engineering  research,  including  autonomous  systems,  vision  systems,  data  fusion,  artificial 
intelligent,  agent-based  modelling,  and  Data  Distribution  Services  (DDS).  In  addition,  he  has 
been  actively  involving  in  systems  engineering  professional  societies,  and  currently  the 
Deputy  President  of  the  Systems  Engineering  Society  of  Australia  (SESA),  and  Associate 
Director  for  Technical  Review  of  INCOSE.  He  is  also  the  Editor  of  the  International  Journal  of 
Intelligent  Defence  Support  Systems  (IJIDSS). 

Jonathan  Hallett  is  the  Systems  Engineering  Team  Leader  at  Deep  Blue  Tech  (DBT)  and  has 
over  27  years'  experience  in  the  Maritime  Defence  Arena. 

A  major  focus  of  Jon's  work  at  DBT  involves  ensuring  understanding  and  consistency  across 
the  design  team  through  process,  practise,  tools  and  training.  Jon  leads  the  requirements 
development  effort  within  DBT  working  with  both  retired  submariners  and  DBT's  engineers. 
He  provides  both  the  co-ordination  and  interpretation  of  the  needs  of  both  the  Operator 
Community  and  the  Design  Engineers  to  ensure  that  they  are  understood  and  translated  into 
unambiguous  requirements  for  the  design  team  to  work  with. 
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Immediately  prior  to  joining  DBT,  Jon  was  a  Consultant  to  the  Finnish  Navy  MCMV  2010 
project  where  he  supported  the  Navy  in  their  requirements  definition,  design  reviews  and 
shipbuilder/ contractor  reviews  leading  up  to  and  during  construction  of  three  new  Mine 
Countermeasures  Vessels. 

Before  this,  Jon  worked  for  QinetiQ  (and  its  predecessors)  in  the  Underwater  Warfare  area.  He 
occupied  roles  such  as  Deputy  Head  of  Science  and  Engineering  -  Underwater  Systems, 
Business  Group  Manager  -  Underwater  Warfare  and  Studies,  Capability  Leader  -  Detection 
Systems  and  Team  Leader  -  Mine  Sweeping  Systems.  During  this  time,  Jon  led  and 
participated  in  numerous  concept  studies  at  business,  platform  and  system  level  across  the 
Underwater  Warfare  spectrum  of  activities.  He  was  the  QinetiQ  Technical  Representative  in 
the  UK  MoD's  Mine  Countermeasures  Equipment  (MCME)  IPT,  Sea  Division  representative 
on  the  QinetiQ  Systems  Engineering  Practitioners  Forum  and  has  represented  the  UK  on  a 
NATO  Mine  Warfare  Project  Group  and  Joint  Research  Programme. 

Workshop  Presentation  and  Outcomes 


Workshop  Session: 

MBSE  Practices  Across  the 
Contractual  Boundary 


1 

Quoc  Do 

Defence  Systems  Innovation  Centre  (DSIC), 

Defence  Systems  Institute  (DASI) 

University  of  South  Australia 

Jonathan  Hallett 

Deep  Blue  Tech  Pty  Ltd 
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Assumptions 

►  Assuming  that  the  Model-Based  Acquisition  is  feasible  and  can 
be  divided  into  the  following  phases: 

►  Model-Support  Acquisition  -  Reflect  current  practices  where 
models  are  used  to  support  various  engineering  activities, 
including  the  production  of  key  documents  for  contractual 
purposes. 

►  Model-Integrated  Acquisition  -  Models  form  part  of  the 
contractual  artefacts  but  as  secondary  or  complementary 
artefacts. 

►  Model-Centric  Acquisition  -  Models  are  the  primary  artefacts 
(with  the  capability  to  generate  required  documentation). 


► 
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Discussion  -  Part  1  (45mins) 

►  Parallel  Groups  Discussion  (1/2): 

►  Qn  I .  What  classes  of  information  in  the  Acquirer’s  Capability 
System  Model  should  be  disclosed  to  the  Provider? 

►  Qn  2.  What  classes  of  information  in  the  Provider’s  System 
Solution  Model  should  be  disclosed  to  the  Acquirer? 

►  Whole  Group  Discussion  (1/2) 

►  Report  from  each  group  for  Qn  I  and  Qn2. 

►  Qn.3.  How  should  the  two  models  be  interfaced? 

5min  Break! 


Discussion  -  Part  2  (45  mins) 

►  Parallel  Groups  Discussion  (1/2): 

►  Group  I: 

Qn  4.  Metamodels  that  could  underpin  items  1-3  ? 

Qn  5.  Model-based  tender  evaluation  by  the  acquirer  ? 

►  Group  2: 

Qn  6.  Model-based  RFT  evaluation  by  the  provider 

►  Whole-Group  Discussion  (1/2) 

►  Report  from  each  group  for  Qn  4,  5  and  6. 

►  Qn.7.  What  are  the  impediments  to  achieving  the  long  term  goal  (i.e. 
Legal  framework  and  IP  issues)? 

End! 
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Workshop  Outcomes 

■  Phased  approach  discussed: 

■  Model-Support  Acquisition  -  Reflect  current  practices  where 
models  are  used  to  support  various  engineering  activities, 
including  the  production  of  key  documents  for  contractual 
purposes. 

■  Model-Integrated  Acquisition  -  Models  form  part  of  the 
contractual  artefacts  but  as  secondary  or  complementary 
artefacts. 

■  Model-Centric  Acquisition  -  Models  are  the  primary 
artefacts  (with  the  capability  to  generate  required 
documentation). 
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■  What  classes  of  information  in  the  Acquirer’s 

Capability  System  Model  should  be  disclosed  to  the 
Provider? 

■  What  wouldn’t  we  pass  across  in  model  form? 

■  Costing  information,  internal  management  information 

■  Sensitive  information  (particularly  prior  to  contract) 

■  Information  that  does  not  make  sense  in  a  model 

■  Functional  model 

■  Possible  for  iterative  approach  between  government  and  industry 

■  Issue  of  how  approvals  of  model  will  take  place  vs  a  document-based 
approach 

■  Rationale  for  performance  figures  and  essential/desirable  etc. 

■  Standards 

■  How  to  specify  which  details  are  relevant  and  testing  against  these 

■  If  conversion  into  model  is  sensible  or  useful 


Support  concept,  test  and  evaluation  information 
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Workshop  Outcomes 

■  What  classes  of  information  in  the  Provider’s  System 
Solution  Model  should  be  disclosed  to  the  Acquirer? 

■  What  wouldn’t  be  passed? 

■  Lower-level  detail  risk  and  cost 

■  System  behaviour  and  Measures  of  Performance 

■  Assumptions,  rationales,  applicable  standards 

■  Test  plans  and  test  cases 

■  Technical  forecast  and  resulting  risks,  Technical  Integrity  Risk 

■  Support  system  model 

■  Anything  as  specified  by  acquirer  -  when  it  makes  sense  to  be  in  a 
model 

■  IP  might  not  be  a  problem  at  bid-time 

■  Systems  model  should  be  abstract  enough  to  avoid  this 

■  More  detailed  model  would  contain  the  IP  information 
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■  How  should  the  two  models  be  interfaced? 

■  Issues: 

■  Need  a  metamodel  defined  by  government  in  order  to  answer 
this 

■  Industry  may  or  may  not  be  able  to  deal  with  standards  or 
tools,  especially  international  bidders 


■  Current  interfacing  standards  lacking,  these  need  to  catch  up 
before  they  can  be  mandated 
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Workshop  Outcomes 

■  Questions  still  to  be  addressed  in  the  future: 

■  Metamodels  that  could  underpin  items  1-3  ? 

■  Model-based  tender  evaluation  by  the  acquirer  ? 

■  Model-based  RFT  evaluation  by  the  provider 

■  What  are  the  impediments  to  achieving  the  long  term  goal  (i.e. 
Legal  framework  and  IP  issues)? 
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11.  KEYNOTE  2 :  Rebuilding  the  Tower  of  Babel  - 
Better  Communication  with  Standards 


Matthew  Hause 

Co-chair  of  the  UPDM  group,  OMG 


Abstract 

The  book  of  Genesis  tells  the  story  of  how  the  peoples  of  the  earth  came  together  to  build  an 
enormous  tower.  To  confound  them  in  their  task,  God  changed  the  languages  of  the  different 
groups  of  people  so  that  they  were  unable  to  communicate.  Since  they  could  not  coordinate 
their  efforts,  the  project  was  abandoned  and  the  different  groups  dispersed  throughout  the 
world. 

The  same  problem  exists  today  in  the  world  of  Architecture  Frameworks.  Although  they 
express  similar  concepts,  interchange  between  the  different  frameworks  is  awkward  at  best, 
time  consuming,  and  leads  to  misunderstanding  and  miscommunication.  This  lack  of 
communication  was  highlighted  in  a  recent  report  on  the  conflict  in  Afghanistan,  where  the 
lack  of  interchange  of  architectures  was  cited  as  a  limiting  factor  in  coalition  efforts  and  may 
have  contributed  to  loss  of  life. 

This  presentation  will  assess  the  current  situation,  examine  international  efforts  to  solve  it, 
and  identify  future  challenges.  This  will  include: 

•  The  role  of  standards  for  collaboration  and  communication 

•  Standards  and  standards  organisations 

•  The  Object  Management  Group  (OMG) 

•  A  brief  history  of  Military  Architectural  Frameworks 

•  The  interoperability  problems  of  frameworks 

•  The  Unified  Architecture  Framework  (UAF)  effort 

•  Using  reference  architectures  to  define  a  common  conceptual  "dictionary" 

•  Systems  engineering,  acquisition,  and  process 

•  Vertical  and  horizontally  complementary  emerging  standards 

•  Future  problems  and  potential  solutions 
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Presenter  Biography 

Matthew  Hause  is  Atego's  Chief  Consulting  Engineer,  the  co-chair  of  the  UPDM  group 
(Unified  Profile  for  DoDAF/MODAF)  and  a  member  of  the  Object  Management  Group 
(OMG)  SysML  specification  team.  He  has  been  developing  multi-national  complex  systems  for 
almost  35  years.  He  started  out  working  in  the  power  systems  industry  and  has  been  involved 
in  military  command  and  control  systems,  process  control,  communications.  Supervisory 
Control  And  Data  Acquisition  (SCAD A),  distributed  control,  and  many  other  areas  of 
technical  and  real-time  systems.  His  roles  have  varied  from  project  manager  to  developer.  His 
role  at  Atego  includes  mentoring,  sales  presentations,  standards  development  and  training 
courses.  He  has  written  a  series  of  white  papers  on  architectural  modeling,  project 
management,  systems  engineering,  model-based  engineering,  human  factors,  safety  critical 
systems  development,  virtual  team  management,  systems  development,  and  software 
development  with  UML,  SysML  and  Architectural  Frameworks  such  as  DoDAF  and  MODAF. 
He  has  been  a  regular  presenter  at  INCOSE,  the  IEEE,  BCS,  the  IET,  the  OMG,  DoD  Enterprise 
Architecture  and  many  other  conferences.  Matthew  studied  Electrical  Engineering  at  the 
University  of  New  Mexico  and  Computer  Science  at  the  University  of  Houston,  Texas.  In  his 
spare  time  he  is  a  church  organist,  choir  director  and  composer. 

Presentation 


Rebuilding  the  Tower  of  Babel 
Better  Communication  Through 
Standards 


Matthew  Hause 

Chief  Consulting  Engineer  -  Atego 

Disclaimer:  The  views  and  opinions  expressed  in  this  presentation  are  those  of 
the  author  and  do  not  necessarily  reflect  the  official  policy  or  position  of  the 
Object  Management  Group  (OMG). 
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•  Barriers  to  communication  and  collaboration 

•  The  interoperability  problems  of  frameworks 

•  Standards  and  standards  organisations 

•  A  brief  history  of  Military  Architectural  Frameworks 

•  Working  Towards  a  Common  Framework 

•  Exchange  of  Architecture  Data 

•  Using  Reference  Architectures  for  a  common 
conceptual  "dictionary" 

•  Systems  engineering,  acquisition,  and  process 

•  Vertical  and  horizontal  complementary  standards 

•  Future  Problems  and  solutions 


LFDm 


□ 


MBSE  Conference  - 


November 201 2 -Matthew Hause  2 


1  |  MBSE  Conference 


Does  this  solve  the  problem? 
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•  The  EU  has  20  recognised  languages,  380  language  permutations 
and  an  annual  interpreting  and  translation  bill  of  €lbn. 

•  EU  institutions  currently  require  around  2,000  written-text 
translators.  They  also  need  80  interpreters  per  language  per  day, 
half  of  which  operate  at  the  European  Parliament. 

•  From  2007  Irish  MEPs  have  been  able  to  speak  in  the  chamber  of 
the  European  Parliament  in  the  Irish  language  with  interpretation, 
though  no  more  than  five  Euro-MPs  have  the  fluency  to  do  so. 

•  Catalans  and  Basques  have  won  more  limited  language  rights. 
Welsh  speakers  are  stepping  up  demands. 


Languages  include  Maltese  despite  the  fact  that  Malta  is  largely 
Anglophone  and  has  just  397,000  citizens. 
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USA/UK:  Two  Countries  Separated  by  a  Common  Language 


Even  speaking  the  same  language  doesn't  always  help.  Picture  this: 


A  man  wearing  a  vest,  pants,  and  a  pair  of  sus 

penders. 

The  American  Image  | 

The  British  Image 

So,  if  communication  is  hard  with  spoken  language,  are  models  the  answer? 


MBSE  Conference  . 
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Unclassified 


. „ The  Afghanistan  Mission  Network  (AMN) 


Reference  Document  3195 

NATO  Consultation,  Command  and  Control  Agency 
Agence  de  Consultation,  de  Commandement  et  de  Conduite  des  Operations  de  I'OTAN 

NATO 


|f  AGENCY 

DEVELOPMENT  OF  THE  AMN  ARCHITECTURE  IN  2010  -  LESSONS  LEARNED 


Torsten  Graeber,  NATO  C3  Agency 

June  2011 


The  Hague 


Unclassified 


•  The  Afghanistan  Mission  Network  (AMN)  is  the  primary  Coalition 
Command,  Control  Communication  and  Computers  Intelligence, 
Surveillance  and  Reconnaissance  (C5ISR)  network  in  Afghanistan 
for  all  ISAF  forces  and  operations.  It  is  a  federation  of  networks 
with  the  AMN  Core  provided  by  NATO  and  national  network 
extensions. 

•  Planning  for  the  AMN  is  supported  by  a  multi-national, 
collaborative  effort  to  develop  and  maintain  the  enterprise 
architecture  for  the  AMN. 

•  This  document  is  a  working  paper  that  may  not  be  cited  as 
representing  formally  approved  NC3A  opinions,  conclusions  or 
recommendations. 
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•  In  2010,  there  was  no  proper  governance  structure  for  the  AMN 
as  a  whole. 


•  Likewise  there  was  no  governance  for  the  development  of  the 
AMN  architecture. 


•  The  development  of  the  architecture  was  primarily  coordinated 
through  the  AWG  consisting  of  the  architects  of  the  nations 
participating  in  the  AMN. 

•  This  AWG  usually  received  ad  hoc  tasking  from  different 
stakeholders  involved  in  the  development  of  the  AMN  without 
clear  leadership  defining  the  goals  and  deliverables  upfront. 


•  As  a  direct  result  of  this  missing  governance  several  issues  arose 
that  had  a  negative  impact  on  the  architecture  development 
work. 
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AMN  Issues  (2) 


These  issues  included: 

-  Different  expectations  on  content  and  usage  of  the  architecture  leading  to 
ever  changing  requirements  and  deliverables 

-  No  enforcement  of  the  architecture  during  implementation 

-  Usage  of  different  architecture  frameworks 

-  Usage  of  different  architecture  tools. 

-  No  interchange  between  the  tools 

In  late  2010,  a  governance  structure  for  the  AMN  was  endorsed  by  Chief 
Of  Staff  SHAPE  and  the  AWG  was  included  in  this  governance 
structure.  As  a  direct  consequence,  the  situation  regarding  clearer 
expectations,  deliverables  and  enforcement  of  architecture  has  been 
improved  in  2011. 

However,  as  the  architects  are  sponsored  by  their  respective 

nations  they  have  to  implement  national  policies  and  requirements. 

so  that  improvements  regarding  the  usage  of  a  single  framework 

and  tool  are  not  to  be  expected. 
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AMN  Recommendations 

i 

•  Recommendation  1 

-  Before  starting,  establish  the  governance  structure. 

•  Recommendation  2 

-  Ensure  availability  of  a  common  infrastructure  allowing  remote  access  to  a 
single  repository 

•  Recommendation  6 

-  Harmonize  national  and  NATO  policies  related  to  architecture 
development  and  reference  architectures. 

•  Recommendation  16 

-  Develop  common  reference  models 

•  Recommendation  18 

-  Standardize  on  one  tool  and  a  single  repository.  Synchronization  is 
expensive  as  is  training. 

•  Recommendation  19 


-  Develop  a  formal  exchange  mechanism  for  data 
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Standards  Are  Important 


•  Great  Baltimore  Fire  of  1 904 

•  Response  from  Philadelphia,  Washington,  New  York,  Virginia, 
Atlantic  City...  hundreds  of  firefighters 

•  Burned  for  two  days,  140  acres 

•  Why? 
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Introducing  OMG 

•  One  of  the  most  successful  forums  for  creating  open 
integration  standards  in  the  computer  industry 

-  Modelling  platforms  (UML,  BPMN,  SysML  &  related  work) 

-  Middleware  platforms  (DDS,  CORBA  &  related  specs) 

-  Vertical  domain  specifications  (Software  Radio,  C4I ....) 

-  Commerically-available  implementations 


*  Member-controlled  ndustr  a  consortium 


-  Both  vendors  and  users 

-  Not-for-profit 

*  Interfaces  freely  available  to  all 

-  Visit  http://www.omg.org 
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Who  Are  OMG? 


Atego 

FICO 

Microsoft 

ASC 

Firestar  Software 

MITRE 

Boeing 

Fujitsu 

British  MOD 

CA  Technologies 

Hewlett  Packard 

National  Archives 

Canadian  DnD 

Hitachi 

NEC 

Citigroup 

HL7 

NEHTA 

Cognizant 

IBM 

NIST 

CSC 

JARA 

No  Magic 

US  DoD/DISA 

Lockheed  Martin 

Northrop  Grumman 

EADS 

Mayo  Clinic 

NSWC&NUWC 

OASIS 

^B=l*ll  l"l 


I  •  '•*'  =ss 


ODNI 

Oracle 

PTC 

Raytheon 

SAP 

Scientific 

Research 

TCS 

THALES 
Unisys 
US  Army 
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One  Standard? 
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no.  Our  job  is  to  minimize  the  cost  of  adaptation... 


A 

/ 

♦ 
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..and  enable  innovation! 
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Historical  Development  of  AF’s. 
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IDEAS  -  Top-Level  Foundation 


■  Developed  by  an  international  group  of  computer  scientists,  engineers, 
mathematicians,  and  philosophers  under  defense  sponsorship. 


■  See  http://www.ideasgroup.org  or  http://en.wikipedia.org/wiki/IDEAS_Group 


f 


mrrm 


Elements  of  Quality  Architecture 


•Policy,  Direction,  Guidance 
• Single  Architecture  Framework 

•  Architecture  Exchange 

•  Architecture  Tools 


DoDAFv2.0 


*  Trained/ Certified  Architects 

Enabling  efficient  and  effective 
acquisition  of  hardware,  software  and 
services  used  by  DoD  in  missions 
deliverables. 

Unified  Architecture  Framework 
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Unified  Architecture  Framework 
NATO  Architecture  CaT 
Introduction 


Mr.  Walt  Okon 
Senior  Architect  Engineer 
DoD  Chief  Information  Officer  Office 
Architecture  and  Interoperability  Directorate 
wait .  o  kon@o  sd.mil 

10-11  September  2012 
Office  of  the  Chief  Information  Officer 

Unclassified 


Unclassified 


?  4.1  ARCHITECTURE  FRAMEWORKS 


4.1.2  Observations  [Need  for  a  Unified 
Architecture  Framework] 

Differences  in  DoDAF,  MODAF,  and  NAF  make  it 
difficult  to  match  the  meta-model  one  to  one. 

—  some  of  the  concepts  in  the  frameworks  have  the  same 
name  but  different  definitions,  i.e.  different  semantics. 

Difficult  to  cross-walk  the  concepts  between  the 
different  frameworks  leads  to  miscommunication 
betw  een  architects  using  different  frameworks. 
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Unified  Architecture  Framework 


Unified  Architecture  Framework  Strategic  Direction 
•Move  towards  a  Single  Architecture  Framework  to  achieve 
Interoperability 

•Development  of  the  AMN  architecture  in  2010 
•Development  of  Unified  Profile  for  DoDAF  and  MODAF 
(UPDM)  Versions  1.0,  2.0,  and  3.0 

•Meeting  at  Object  Management  Group  (OMG)  March  2012 

•Ideas  Meeting  in  June  2012 

•Plan  for  NATO  CAT  workshop  10/11  Sept  2012 

Launchpad  for  Unified  Architecture  Framew  ork 
(UAF) 
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Architecture  Framework  Convergence  Vision 


■  JCJDS  &  NR-KPP 

•  Applicability  beyond  C4ISR 

■  Use-based 

•  Integrated  Architecture 


1  Fit-for-purpose 
1  Data-centric 
architecture 
1  Improved  models  of 
systems,  services, 
capabilities,  rules, 
measures 


■  Urgent  CRs 

■  52  AlXSD 

•  IDEAS  Foundation 
vl.O  fixes 


■  Federal 


■  26  AV/OV/SV/TV  views 

■  Linked  to  I &S  policies 
•  CADM2.0 


C4ISR  F/W  vl.O 


Framework  Objective: 

♦Achieve  a  single  integrated  Architecture  Framework  for 
interoperability. 

•Achieve  a  US,  Canada,  and  United  Kingdom  single  Framework 
with  a  common  Data  Meta  Model 
•Achieve  alignment  with  the  US  Government  Common 
Approach  to  Enterprise  Architecture 


m 


19  June  2012 
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•  UPDM  is  a  standardized  way  of  expressing  DoDAF  and 
MODAF  artefacts  using  UML  and  SysML 

-  UPDM  is  NOT  a  new  Architectural  Framework 

-  UPDM  is  not  a  methodology  or  a  process 

-  UPDM  implements  DoDAF  2.0,  MODAF  &  NAF 

•  UPDM  was  developed  by  members  of  the  OMG  with 
help  from  industry  and  government  domain  experts. 

•  UPDM  is  a  DoD  mandated  standard  and  has  been 


implemented  by  multiple  tool  vendors. 

•  UPDM  is  a  proof  of  concept  of  the  UAF 

•  Future  versions  of  UPDM  will  implement  the  UAF 
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Data  Exchange  Case  Study:  CAD  (1)  | 


Computer  Aided  Design  (CAD)  data  exchange  involves  a  number 
of  software  technologies  and  methods  to  translate  data  from  one 
Computer-aided  design  system  to  another  CAD  file  format.  This 
PLM  technology  is  required  to  facilitate  collaborative  work  (CPD) 
between  OEMs  and  their  suppliers. 

The  main  topic  is  with  the  translation  of  geometry  (wireframe, 
surface  and  solid)  but  also  of  importance  is  other  data  such  as 
attributes;  metadata,  assembly  structure  and  feature  data. 

There  are  basically  three  methods  of  transferring  data  from  one 
CAD  system  to  another. 

-  Direct  CAD  system  export/import 

-  Direct  3rd  party  translators. 

-  Intermediate  data  exchange  formats 
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•  Intermediary  Format. 

-  Some  by  standards  organisations 

-  Others  are  private  and  regarded  as  quasi  industry  standards. 

•  Examples 

-  STEP  -  ISO  10303,  a  replacement  for  IGES  and  VDA-FS  with  the 
CAD  specific  parts:  STEP  AP203  and  AP214:  Mechanical  CAD 
systems 

•  STEP  AP210:  CAD  systems  for  printed  circuit  board 

•  STEP  AP212:  CAD  systems  for  electrical  installation  and  cable  harness 

•  STEP-NC  AP238:  CAD,  CAM,  and  CNC  machining  process  information 

•  STEP  AP242,  Managed  Model-Based  3D  Engineering  -  the  merging  of 
the  two  leading  STEP  application  protocols,  AP  203  and  AP  214 

-  Others:  IGES,  VDA-FS,  DXF,  Parasolid  XT,  JT  Open,  DRG,  etc. 

•  In  short:  multiple  incompatible  standards  offering  partial 


MBSE  Conference  .. 


•  PES  is  a  direct  translation  of  a  DoDAF  model  into  XML  based 
on  the  data  in  the  DoDAF  2  Data  Dictionary  and  Viewpoint 
Mappings 

•  Proprietary  standard,  developed,  owned  and  maintained  by 
the  DoD. 

•  New  versions  of  DoDAF  means  new  versions  of  PES 
automatically  generated  from  the  DM2. 

-  No  tools  to  support  backwards  compatibility  of  a  means  of  converting 
between  different  versions  of  the  PES. 

-  No  formal  verification  and  validation  of  the  DM2. 


Currently  no  significant  level  of  support  within  tools. 

Tests  of  complete/interoperable  implementation  of  PES 
across  tools  have  not  been  performed  nor  have  interchange 
standards  been  defined. 


ST 
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DoDAF  Physical  Exchange  Specification  (PES)  -  A  Solution? 


•  Parsing  a  PES  file  will  be  problematic 

•  In  the  DM2  there  is  only  one  definition  of  activity.  Is  this: 

-  a  project  activity? 

-  a  system  activity? 

-  a  service  activity? 

-  an  operational  activity? 

-  All  of  them? 

•  How  does  one  know  to  which  model  the  activity  belongs? 

•  The  PES  will  need  significant  work  before  it  can  be  used  to 
successfully  interchange  models. 

•  Most  important,  it  will  not  solve  the  interchange  problem 
between  DoDAF  and  MODAF  models. 


•  The  DoD  is  considering  RDF  as  an  alternative. 


upom 
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Modelling  Tool  Interoperability 

*  OMG  publishes  standard  for  MOF  model  interchange 

-  XML  Metadata  Interchange  (XMI) 

-  UML,  SysML,  UPDM  all  based  on  MOF  models 

*  Sadly,  publishing  standard  doesn’t  guarantee  separate 
good-faith  implementations  can  interchange  models 

-  Tiny  ambiguities  &  programming  errors  kill  interoperability 

*  Multi-vendor  testing  drives  out  bugs,  assures  interoperability 

-  OMG  Model  Interchange  Working  Group  compiles  tests 

-  Vendors  run  tests,  fix  their  tools  or  file  spec,  bug  reports 

-  UPDM  OV-2  interchange  demonstration  at  April  2012  DoD 
Enterprise  Architecture  Conference 

-  Result:  assures  tool  interoperability  &  model  longevity 

-  UPDM  &  OMG  27  - 
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Reference  Architectures- A  common  dictionary 


•  Provides  a  template  solution  for  an  architecture  for  a 
particular  domain. 

•  Provides  a  common  vocabulary  to  discuss  implementations 

-  Stresses  commonality. 

•  Defines  functions  and  interfaces  and  interactions 

•  Can  be  defined  at  different  levels  of  abstraction. 

•  Set  of  patterns  of  successful  implementations. 

-  Shows  how  to  compose  these  parts  together  into  a  solution. 

-  Will  be  instantiated  for  a  particular  domain  or  for  specific  projects. 

•  Accelerates  delivery  through  the  re-use  of  an  effective 
solution  and  provides  a  basis  for  governance  to  ensure  the 
consistency  and  applicability  of  technology  use. 

•  Dependent  on  a  common  data/interchange  format,  storage 
and  distribution  capability,  configuration  management,  etc. 
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Architecture  Reference  Models 


•  The  intent  of  this  Australian  Government  Architecture  (AGA)  framework  is  to 
assist  in  the  delivery  of  more  consistent  and  cohesive  services  to  citizens  and 
support  cost-effective  delivery  of  Information  and  Communications  Technology 
(ICT)  services  by  government,  providing  a  framework  that: 

-  provides  a  common  language:  provides  a  common  language  for  agencies  involved  in 
the  delivery  of  cross-agency  services 

-  enhances  collaboration:  supports  the  identification  of  duplicate,  re-usable  and 
sharable  services 

-  assists  in  describing  and  analysing  ICT  investments:  provides  a  basis  for  the  objective 
review  of  ICT  investments  by  government 

-  assists  in  transforming  Government  (citizen-centric,  results-oriented,  market-based): 
enables  more  cost-effective  and  timely  delivery  of  ICT  services  through  a  repository 
of  standards,  principles  and  templates  that  assist  in  the  design  and  delivery  of  ICT 
capability  and,  in  turn,  business  services  to  citizens. 

Australian  Government  Architecture  Reference  Models,  August  2011  Version  3.0 
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Systems  Engineering,  Acquisition,  and  1 

Process 

•  National  acquisition  processes  have  evolved  over  time 

-  Unique  to  each  country  and  established  by  law 

-  Fiendishly  complex 

-  Not  necessarily  fit  for  purpose 

-  Resistant  to  change 

•  Adoption  of  a  common  process  across  countries  is  neither 
likely  nor  practical 

-  Need  to  concentrate  on  MBSE  best  practice 

-  Architecture  standards 

-  Certified  Architect  Standards 

-  System  Lifecycle  Standards  (15288) 

-  Competency  Frameworks 

-  Etc. 

•  Most  important,  a  process  should  NOT  tie  itself  directly  to  a 
specific  tool  or  tool  vendor. 
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Vertical  and  Horizontal  Complementary  Emerging  Standards 


*  CA-FEA:  The  Common  Approach  to  Federal  Enterprise 
Architectures 

♦  UML:  The  Unified  Modelling  Language. 

*  SysML:  The  Systems  Modelling  Language 

•  SoaML:  The  Service  Oriented  Architecture  language 

*  NIEM:  UML  Profile  for  NIEM  -  provides  a  common  method  for 
defining  XML  schema  conforming  to  the  NIEM  Specifications 

♦  IEPV:  Information  Exchange  Policy  Vocabulary  -  provides  a 
method  for  defining  the  business  rule  for  the  aggregation, 
transformation,  tagging  and  filtering  data  and  information  to  a 
specified  message  format. 

•  SOPES  IEDM:  Codified  set  of  business  rules  for  the  JC3IEDM 
(STANAG  5525)  conforming  to  compliance  point  1  of  the  IEPV 

•  Etc. 
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Common  Approach 


National  IT  Architecture  Movement  in  the  United 
States  across  all  Government  Departments, 
Agencies,  and  Organizations 


Federal,  State,  and  Local 


Industry 

Academia  (Colleges  and  Universities) 


Unclassified 


33 


116 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0734 


Unclassified 


Common  Approach 


Increasing  Shared  Approaches 
To  Information  Technology 
Services 

•Implements  Governance  Process 

•Provides  Authority  to  the  Common 
Approach  to  a  Unified  Architecture 
Framework 

•Provides  Standards  Methods  and 
Tools 

•Design  and  Implement  Shared 
Services 

•Design  architectures  that  facilitates 
interoperability  and  information¬ 
sharing 


EXECUTIVE  OFFICE  OF  THE  PRESIDENT 
OFFICE  OF  MANAGEMENT  AND  BUDGET 
WASHINGTON.  DC  20503 


MEMORANDUM  FOR  FEDERAifAGENCY  CHIEF  INFORMATION  OFFICERS 


FROM:  Steven  VanRoek/l  _ 

Federal  Chief  Intamretfon 

SUBJECT :  Increasing  Shared  Approaches  (o  Information  Technology  Services 

This  memorandum  provides  Federal  Agencies  with  policy  guidance  and  management  tools  to  use 
in  increasing  shared  approaches  to  information  technology  (IT)  service  delivery  across  mission,  support, 
and  commodity  areas  Taking  a  shared  approach  will: 

•  Improve  return  on  investment  across  the  Agency’s  entire  IT  portfolio  through  the  coordinated  use  of 
TcchStat  program  reviews';  PonfolioSUrt  investment  reviews';  and  the  consolidation  of  commodity 
IT  systems,  services,  and  related  contracts’  as  described  in  the  Information  Technology  Shared 
Services  Strategy  that  accompanies  this  memo. 

•  Close  productivity  gaps  by  implementing  integrated  governance  processes  and  innovative  fT  service 
solutions  at  the  program,  bureau  and  agency  levels.  Agency  implementation  is  to  be  consistent  with 
guidance  contained  in  the  Federal  Cloud  Computing  Strategy*  and  Digital  Government  Strategy f,  as 
well  as  tile  Common  Approach  to  Federal  Enterprise  Architecture  (Common  Approach)  that 
accompanies  this  memo.  The  Common  Approach  provides  agile,  standardized  methods  and  tools  for 
designing  else  next  generation  of  IT  resources  and  shared  services  that  Federal  Agencies  will  need  to 
successfully  accomplish  their  missions  in  the  face  of  tight  resources  and  rising  customer  needs. 

•  Increase  communications  with  stakeholders  as  shared  service  managing  partners,  customers,  and 
providers  work  together  to  ensure  transparency,  accountability,  and  ongoing  collaboration  in  the  full 
lifccvcJc  of  intra-  and  inter-agency  IT  shared  service  activities.  Collaboration  resources  that  are 
available  to  support  this  are  CIO.gov,  ITDashboani.gov,  Performance.gov,  and  Businesst.'SA.gov. 

To  ensure  that  IT  shared  services  are  implemented  in  a  coordinated  and  expedited  manner. 
Federal  Agency  Chief  Information  Officers  (CIOs)  will  submit  an  “Enterprise  Roadmap”  to  OMB  by 
August  31. 2012  that  covers  Fiscal  Years  (FY)  2012-201$  and  includes: 

(1)  Business  and  Technology  Architecture:  a  high-level,  integrated  description  of  the  agency’s 
business  objectives  and  enabling  IT  capabilities  across  all  operating  units  and  program  areas  • 
using  enterprise  architecture  concepts  and  methods  from  the  Common  Approach  to  describe  the 
agency-wide  current  architecture,  future  architecture,  and  transition  plans.  The  transition  plan 
will  include  a  description  of  the  two  IT  areas  that  Federal  Agencies  will  migrate  to  a  shared 
service  model  by  December  31, 2012  in  accordance  with  OMB  guidance. 

(2)  IT  Asset  Inventory  (Appendix  1):  a  list  of  IT  assets  agency-wide  to  include  all  IT  systems*  and 
services  that  support  mission,  administrative,  and  commodity  IT  programs,  using  the  Federal 
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•  Systems  of  systems  will  grow  in  complexity  and  scale 

-  Architectures  will  be  necessary  for  understanding  and 
governance 

—  Essential  for  proper  management  and  control 

-  Tools  will  need  to  evolve  to  support  this 

•  Individual  national  support  of  proprietary  architecture 
frameworks  will  become  unsupportable 

-  Unaffordable 

-  Not  interoperable 

-  A  barrier  to  communications 

•  The  ROI  case  for  MBSE  has  not  yet  been  made 

-  Some  evidence  exists,  but  it  is  not  yet  overwhelming 

-  PowerPoint  Engineering  is  still  the  status  quo 
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•  Development  of  the  UAF  will  solve  many  problems  (but  not  all) 

-  Requires  immediate  support  and  funding  from  national  governments 

-  A  change  from  "individual  cars"  to  shared  transport 

-  Local  variants  will  be  necessary 

•  An  interchange  standard  will  be  essential 

-  Problems  with  PES  or  its  replacement  must  be  overcome 

-  Work  on  interchange  using  RDF  is  looking  promising 

•  Reference  Architectures  need  to  be  created  and  shared 


-  At  both  the  capability  and  component  level 

•  A  fundamental  change  in  process  needs  to  happen 

-  MBSE  needs  to  change  from  "extra  work"  to  "how  things  are  done" 

-  Tools  need  to  evolve  to  better  enable  this  change  in  process 

•  The  case  for  MBSE  Must  be  made 


-  Industry  partners  Must  publish  more  success  stories 

-  Governments  Must  require  MBSE  starting  with  the  concept  phase,  the  bid 
process  and  throughout  the  acquisition  lifecycle 
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Matthew.Hause@Atego.com 
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12.  A  Proposed  Pattern  of  Enterprise  Architecture 


Dr  Clive  Boughton 
Australian  National  University 


Abstract 

The  latest  versions  of  the  Department  of  Defence  and  Ministry  of  Defence  Architecture 
Frameworks  (DoDAF  and  MoDAF),  as  well  as  the  Object  Management  Group's  Unified 
Profile  for  DoDAF  and  MoDAF  each  employ  a  meta-model,  thus  providing  a  basis  for 
effective  implementation  of  tools  for  constructing  consistent  architecture  descriptions. 

UPDM  comprises  extensions  to  both  OMG's  Unified  Modelling  Language  (UML)  and  Systems 
Modelling  Language  (SysML),  and  thus  provides  for  architectural  descriptions  that  contain  a 
rich  set  of  (formally)  connected  DoDAF/ MoDAF  viewpoints  expressed  in  a  form  familiar  to 
those  who  use  UML  and  SysML. 

These  represent  significant  advancements  that  enable  architecture  trade-off  analyses, 
architecture  model  execution,  requirements  traceability,  and  speedier  transition  to  systems 
design  and  implementation.  All  very  useful  to  both  the  enterprise  architect  and  the  solutions 
architect.  But  is  there  more  that  can  be  done,  especially  for  those  who  should  contribute  input 
to  the  enterprise  architecture? 

In  this  paper  an  extra  model/ view  in  the  form  of  a  pattern  is  described  that  is  intended  to  aid 
in  the  development  of  enterprise  architectures  (EA),  both  small  and  large.  The  proposed 
pattern  of  EA  is  developed  using  information  extracted  from  the  Computer  Emergency 
Response  Team  Resilience  Maturity  Model  (CERT  RMM)  and  the  Capability  Maturity  Model 
Integrated  (CMMI)  for  Acquisition,  and  for  Services  as  well  as  the  People  Maturity  Model. 

Although  not  completed,  the  pattern  of  E A  is  developed  to  the  extent  that  some  benefits  from 
its  use/ application  across  several  types  of  organisation  are  readily  apparent.  One  of  its  main 
benefits  is  to  allow  business  analysts/ engineers  early  capture  of  EA  requirements.  A  further 
benefit  is  that  the  'pattern'  should  be  easier  for  executive  decision  makers  to  appreciate  and 
understand  -  without  feeling  technically  incompetent. 
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Just  throwing  in  some 
ideas  &  concepts! 


Maybe  some  light  bulb 
moments  for  you? 


* 


Not  quite  finished  yet! 
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Improvements^ What  prompted  my  thinking? 


Severally:  Architecture,  Processes,  Decisions 

•  Interesting  experiences  and/or  observations 

♦  Especially  decisions  and  processes  lacking  ‘logic’ 

•  Seeing  people  reel  from  too  much  (mindless)  change 

♦  As  well  as  information  overflow 

•  Seeing  repercussions  of  many  COTS  ‘solutions’ 

♦  A  COTS  gives  us  80%  of  the  solution!!  A  silver  bullet?! 

»  Little  /  no  analysis  of  options  -  a  ‘shaped’  OCD 

•  Continuing,  awkward  integrations  of  business  &  IT 

♦  Even  though  ‘architecture’  has  been  around  for  a  while 

♦  Despite  the  recognised  imperative  of  up-to-date  information 

•  Perhaps  because  I  am  confused 

♦  After  all  everything  is  getting  more  complex  -  isn’t  it? 

♦  Cost,  time  and  quality  still  matter  -  don’t  they? 
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What  prompted  my  thinking? 


Stuff  that’s  not  being  referred  to  or  used  often 

•  Architecture  Frameworks  -  in  last  5  years 

•  DoDAF,  MoDAF,  latest  versions  are  more  holistic  wrt  EA 

•  UPDM  becoming  very  mature  and  supports  MBSE  well! 

•  TOGAF  seems  to  have  significant  following  -  doesn't  seem  to 
support  MBSE. 

•  CMMI  in  last  10  years  (from  SEI  &  CERT) 

•  Development 

■  Covers  systems  &  software  -  roots  from  SW-CMM  1991 

•  Services 

■  Greater  than  80%  of  world  economy 

■  Greater  than  50%  US  DoD  acquisitions. 

•  Acquisition 

■  Most  enterprises  do  this  -  began  1994 

•  Resilience 

■  Extends  Services  to  include  greater  emphasis  on  business  survival 

•  People 

■  For  developing  individual  capability  to  shaping  the  workforce 
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‘Business’  Organisations 

•  Most  deemed  to  be  governed by  ‘business  strategy’ 

►  Strategic  directions  -  driven  by  'environment'  (change). 

►  Business  needs -driven  by  'market'  (change. 

►  Operational  needs -driven  by  'technology'  (change). 

►  Efficiency  needs -driven  by  'economy'  (change). 

•  Most  interventions  cause  significant  and  costly 
disruption 

►  Few  interventions  are  successful  -  particularly  large  ones 

■  Don't  live  up  to  expectations  or  ‘improve  things' 

■  Risk!  What's  that?  We'll  be  right  mate! 

■  Take  years  to  facilitate  and  get  into  shape 

■  Leave  a  big  *?'  regarding  value  for  money 

■  Leave  mostly  LOSERS 


Proposed  Pattern  of  EA 


Clive  Boughton 


122 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0734 


Observations  -  2 


'Business’  Organisation  Architectures 

•  Enterprise  Architecture: 

►  Mostly  immature  -  or  do  not  really  exist 

►  Typically  'controlled'  by  IT  infrastructure 

►  Infected  with  legacy  constraints 

►  Minimally  documented  -  if  they  do  exist 

►  Rarely  articulated  as  being  associated  with  'business' 

►  . 

•  Systems  Architecture: 

►  Usually  seen  as  only  the  IT  stuff 

►  Sometimes  seen  as  the  EA  ( because  of  multiple  SAs) 

►  Sometimes  appears  completely  separate  to  EA 

►  . 
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'Business’  Organisation  Maturity  Essentials 

•  Business 

►  Structure 

►  Nature 

►  Stability 

•  Management 

►  Style 

•  Capability 

►  Consistency 

►  Professional  depth 

•  Resiliency 

►  ‘Ready’  for  impacts  of  change 

►  Survivability 
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Software 

Improvements 


Overview  of  inputs 


Organisations  and  their  business 

•  Do  they  know  what  they  do? 

•  Do  they  know  their  business  drivers  (and  changers)? 

•  Are  they  struggling  with  the  IT  behemoth? 

Enterprise  architecture 

•  Is  it  all  determined  from  OV-1  ? 

•  Is  it  overborne  by  IT  constraints? 

•  A  holistic  view  or  a  bitsy  view  (system-by-system)? 

Architectural  frameworks 

•  DoDAF  emphasis  now  on  data-centric  process! 

•  DoDAF  in  context  with  FEA  and  OMB’s  EAAF! 
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Software  |~] 

Improvements ^ 

Optimal  B-A-M  overlap? 

Does  it  matter? 


Architecture  Business 

m  B 


Maturity 


Probably  only  small  overlap  for 
orgs.  subject  to  continuous 
change. 
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Should  this  be 
other  way 
around? 


Suspect  larger  overlap  for 
orgs.  subject  to  low  levels 


of  change. 
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Is  this  a  starting  point  for  EA? 
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Improvemen^ljl^^^Jj  Is  this  a  way  to  get  a  grip? 
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OooKay! 

So,  let  me  see 
what  you  cook 


Answer:  To  last  2  questions 


Perhaps! 


BUT  Conceptualisation  is  key! 


Proposed  Pattern  of  EA 


Clive  Boughton 


Perceptions! 


CONCEPTUALISATION!  ? 


C  Anyway!  I’m  no  geek. 
So,  do  I  need  to  know? 


Is  that  an  ORG-CHART? 


Proposed  Pattern  of  EA 


Clive  Boughton 


126 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0734 


Properties 


If  thinking  about  systems  and  their 
conceptualisation  it’s  appropriate  to 
study  some  basic  properties! 

DATA  PROCESS  STATE 
PROCESS  STATE  DATA 
STATE  DATA  PROCESS 

Treat  a  business  organisation  as  a  complex  real-time  system 
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Services 

•  Form  a  layer,  decoupling  Operational  activities  from 
organizational  arrangements  of  resources,  such  as  people 
and  information  systems. 

•  Form  a  pool  that  can  be  orchestrated  in  support  of 
operational  activities,  and  the  Operational  activities  define 
the  level  of  quality  at  which  the  Services  are  offered. 

Capabilities 

•  Relate  to  Services  via  the  realization  of  the  Capability  by  a 
Performer  that  is  a  Service. 

•  In  general,  a  Service  would  not  provide  the  Desired 
Effect(s),  but  rather,  [provide]  access  to  ways  and  means 
{activities  &  resources)  that  would. 

Proposed  Pattern  of  EA  Clive  Boughton  15 
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Improvement sjf  Clues:  CERT-RMM  &  CMMI-Svc 


Operations 

•  Realise  Capabilities. 

Systems 

•  Help  fulfill  Capability  requirements. 

•  Support  Operational  activities  &  facilitate  information 
exchange. 
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lmprovement$|j|^ Clues:  Conceptual  Data  Model 


DIV-1  (new  in  DoDAF2.0): 

•  Addresses  the  information  concepts  at  a  high-level  on 
an  operational  architecture. 

•  Used  to  document  the  business  information 
requirements  and  structural  business  process  rules 
of  the  architecture. 

•  Describes  information  that  is  associated  with  the 
information  of  the  architecture.  Includes  information 
items,  their  attributes,  and  their  inter-relationships. 

The  intended  usage  of  the  DIV-1  includes: 

•  Information  requirements 

•  Information  hierarchy 


Proposed  Pattern  of  EA  Clive  Boughton  18 


Software  [~] 

Improvements 

Clues:  Logical  Data  Model 

DIV-2: 

•  Allows  analysis  of  an  architecture's  data  definition 
aspect,  independent  of  implementation  /  product 
specific  issues. 

•  Provides  a  common  data  definition  dictionary  to 
consistently  express  model  descriptions  including  - 

►  Information  in  an  OV-1  High  Level  Operational  Concept 
Model  or  an  Activity  Resource  flow  object  in  an  OV-5b 
Operational  Activity  Model. 

►  Entities  &  elements  constrained  and  validated  by  capture  of 
business  requirements  in  an  OV-6a  Operational  Rules  Model. 

►  Information  content  of  messages  that  connect  life-lines  in  an 
OV-6c  Event-T race  Description. 

►  Elements  required  due  to  Standards  in  the  StdV-1  Standards 
Profile  or  StdV-2  Standards  Forecast. 
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lmprovements||||^^^|  Clues:  Logical  Data  Model 


DIV-2: 

•  Bridges  the  gap  between  the  conceptual  data  model 
and  physical-levels. 

•  Introduces  attributes  and  structural  rules  that  form 
the  data  structure. 

•  Provides  more  detail  than  the  conceptual  data  model. 

•  Communicates  more  to  the  architects  and  systems 
analysts  types  of  stakeholders. 
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Activity:  Work,  not  specific  to  a  single  organization,  weapon  system  or 
individual  that  transforms  inputs  (Resources)  into  outputs  (Resources)  or 
changes  their  state. 

Resource:  Data,  Information,  Performers,  Materiel,  or  Personnel  Types  that 
are  produced  or  consumed. 

•  Materiel:  Equipment,  apparatus  or  supplies  that  are  of  interest,  without 
distinction  as  to  its  application  for  administrative  or  combat  purposes. 

•  Information:  The  state  of  a  something  of  interest  that  is  materialized  -  in  any 
medium  or  form  -  and  communicated  or  received. 

►  Data:  Representation  of  information  in  a  formalized  manner  suitable  for 
communication ,  interpretation ,  or  processing  by  humans  or  by  automatic  means. 
Examples  could  be  whole  models ,  packages,  entities,  attributes,  classes,  domain 
values,  enumeration  values,  records,  tables,  rows,  columns,  and  fields. 

►  Architectural  Description:  Information  describing  an  architecture  such  as  an  OV- 
5b  Operational  Activity  Model. 
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lmprovemen|S|||^ DoDAF  Meta-Model  Definitions 


•  Performer:  Any  entity  -  human,  automated,  or  any  aggregation  of  human 
and/or  automated  -  that  performs  an  activity  and  provides  a  capability. 

►  Organization:  A  specific  real-world  assemblage  of  people  and  other  resources 
organized  for  an  on-going  purpose. 

►  System:  A  functionally,  physically,  and/or  behaviorally  related  group  of  regularly 
interacting  or  interdependent  elements. 

►  Person  Type:  A  category  of  persons  defined  by  the  role  or  roles  they  share  that 
are  relevant  to  an  architecture. 

►  Service:  A  mechanism  to  enable  access  to  a  set  of  one  or  more  capabilities, 
where  the  access  is  provided  using  a  prescribed  interface  and  is  exercised 
consistent  with  constraints  and  policies  as  specified  by  the  service  description.  The 
mechanism  is  a  Performer.  The  capabilities  accessed  are  Resources  -  Information, 
Data,  Materiel,  Performers,  and  Geo-political  Extents. 
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Capability:  The  ability  to  achieve  a  Desired  Effect  under  specified 
(performance)  standards  and  conditions  through  combinations  of  ways  and 
means  (activities  and  resources)  to  perform  a  set  of  activities. 

Condition:  The  state  of  an  environment  or  situation  in  which  a  Performer 
performs. 

Desired  Effect:  A  desired  state  of  a  Resource. 

Measure:  The  magnitude  of  some  attribute  of  an  individual. 

Measure  Type:  A  category  of  Measures. 

Location:  A  point  or  extent  in  space  that  may  be  referred  to  physically  or 
logically. 
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lmprovemenl$|j|||^^^|  DoDAF  Meta-Model  Definitions 


Guidance:  An  authoritative  statement  intended  to  lead  or  steer  the  execution 
of  actions. 

•  Rule:  A  principle  or  condition  that  governs  behavior;  a  prescribed  guide  for 
conduct  or  action. 

►  Agreement:  A  consent  among  parties  regarding  the  terms  and  conditions  of 
activities  that  said  parties  participate  in. 

►  Standard:  A  forma!  agreement  documenting  generally  accepted  specifications  or 
criteria  for  products,  processes,  procedures,  policies,  systems,  and/or  personnel. 

Project:  A  temporary  endeavor  undertaken  to  create  Resources  or  Desired 
Effects. 

Vision:  An  end  that  describes  the  future  state  of  the  enterprise,  without 
regard  to  how  it  is  to  be  achieved;  a  mental  image  of  what  the  future  will  or 
could  be  like. 

Skill:  The  ability,  coming  from  one's  knowledge,  practice,  aptitude,  etc.,  to  do 
something  well. 
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'Business’  Organisations 

•  Usually  driven  by  desired  goals  &  have  a  mission 

•  Usually  comprise: 

►  Financial  ‘systems’ 

►  Human  resource  ‘systems’ 

►  Assets  (property,  equipment,  people) 

►  Administrative  ‘systems’ 

•  Typically  provide: 

►  Services  (and  their  maintenance) 

►  Products  (and  their  maintenance) 

•  Sometimes  undertake: 

►  Acquisitions 

►  Developments 
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Software 

Improvements 


Basic  Properties  -  2 


'Business’  Organisations 

•  Typically  see  assets  as: 

►  Buildings 

►  Vehicles 

►  Furniture 

►  Computing  equipment 

►  . 

•  Often  DONT  see  assets  as: 

►  People 

►  Information 

■  client  information  maybe  an  exception 

►  . 
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A  Conceptual  Model? 

SWOT 


Goals 

Mission 


Business 
Requirements 


Legal 
Requirements 


derived  from 


Standards 
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Software 

Improvements 


Adding  Attributes 


Business 

Requirement 
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Availability 
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Description 
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Description 

Mission 

Role 

Availability 
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Asset  Name 
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Availability 
Location 

CommissionDate 

RetvementPate 
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Adding  Multiplicity 


Business 

Requirement 
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StrategicObjective 
Availability 
Recover  abAty 
ValidationLevel 
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Ownershit^^^^ 
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Service 


Description 
WhenReqmred 


1 


1..* 
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Asset 

AHSiB - 

AssetName 

Description 

Availability 
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CommissionDate 
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Software 

Improvements 


Adding  Roles 


Business 

Requirement 


ReqlD 
StrategicOCyecfcve 
Availability 
Recover  ab<My 
ValidationLevel 
CSF 

Authority 

ResponsO*ty 

Ownership 


1..* 


1./ 


derivesFrom 


isResotvedTo 


Service 


Reauirement 

S  II  vl  I  Ivl  1 1 

SvcReqiD 

Description 

WhenHeq^efl 


1„* 


maySupport 


isMetUsing 


Asset 

AssetiS - 

As  set  Name 
Description 
Availability 
Location 

CommissionDate 

Ret*ementDate 


Defined 

Service 


SvcReqiD 

Asset  ID 

SvcName 
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Mission 
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Availability 
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Improvements Measures  &  Monitoring  Data 


Software 

Improvements 


Including  Projects 


mayBeOetermnecffly  1./ 


1..*  mayDetennine 


Reg  lb 

Strateg»cObjective 

Availability 

Recoverability 

VahdabooLevel 

CSF 

Authority 


^jner^u 


PfOjlD 

SvcReglO 

Objective 


isAchiavedThru 


Delivered  Service 


^IB- 

said 

Availabdityftocord 

AetuaiStartOate 

ActuaiCompieiionDate 


Service  Agreement 

5Aib  - 

Requestor 

Description 

Objective 


RequvedStartDate 

RequiredCompletiofiOale 


ComnvsMonOate 


Owner 

Capacity 
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NegotiatonsComplete  (Finalised  Contract) 
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Software  [~| 

Improvements,-  r~M 

An  Essential  Model 

Advantages 

•  Provides  the  ‘essential’  fabric  of  an  enterprise 

►  Data  PLUS  data  relationships  -  NOT  just  data! 

►  Better  still  -  NORMALISATION  (for  continuing  integrity) 

►  IMPLEMENTATION-FREE  (requirements  are  the  changer) 

►  T raceability  enables  easy  analysis  of  impacts  of  change(s) 

►  Allows  for  ‘optimum’  implementation 

►  Supports  incremental  development 

•  State  model  can  be  easily  added 

►  Introduces  ‘events’  that  drive  or  change  the  system 

►  Further  enables  discovery  of  impacts  of  change  before 
implementing  any  change 

•  Process  models  can  be  easily  added 

►  Includes  actions  to  be  taken  when  particular  events  occur 

►  Defines  ‘expected’  behaviour 
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Information  Model 


Advantages 

•  Can  obtain  a  comprehensive  (logical)  model: 

►  Of  essential  enterprise  requirements  -  which  can  be  used  to 
build  and  /  or  evaluate  any  particular  enterprise 

►  Of  architectural  and  design  building  blocks  that  are  free  from 
any  (vendor)  implementation 

►  Based  on  other  mature  models  concerning  enterprises  (e.g., 
CERT-RMM,  CMMI-Svc) 

►  That  can  be  ‘mapped’  to  existing  enterprise  when  it’s  difficult 
to  comprehend  what  to  do  when  undertaking  ‘changes’ 

►  That  enables  more  effective  and  more  timely  enterprise 
process  improvement 

►  Useful  for  simulation  and  automated  development - 
NIRVANA  (for  some)! 

•  Strongly  supports  M BSE!! 


Proposed  Pattern  of  EA 


Clive  Boughton 


lmprovement$|^^j  Usefulness  of  Model 


To  Executives 

•  Only  a  few  concepts  and  representations  to  learn  and 
remember  -  and  they  can  be  kept  simple! 

•  Not  limited  to  OV-1  (/  think  this  is  good!) 

•  Aligns  better  with  basic  visualisations  of  what  a 
business  organisation  does. 

•  Enables  simplified  views  -  for  different  levels  of 
understanding 

•  Discussions  can  remain  conceptual  in  nature  - 
there’s  no  technology  but  an  executive  has  a  greater 
opportunity  to  understand  whether  an  implementation 
technology  has  been  successful  or  not. 
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Usefulness  of  Model 


To  Architects 

•  Less  translation  is  required  before  discussions  with 
executives. 

•  Provides  a  common  point  of  understanding. 

•  Traceability  to  requirements  enables  impacts  of 
changes  to  be  discovered  and  described  more  easily. 

•  Can  use  model  to  more  quickly  undertake 
architectural  and  design  tradeoffs  -  AADL  and  more 
advanced  modeling  tools  will  be  very  useful  here. 

•  Can  use  model  to  effect  simulation  -  again  AADL  and 
the  more  advanced  modeling  tools  may  be  very 
useful. 
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Software 

Improvements 


A  DoDAF  2.0  meta-model 
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13.  Incorporating  MBSE  into  SoS  Engineering  Practice 

1  2 

Pin  Chen  and  Mark  Unewisse 

1Maritime  Operations  Division,  DSTO  and  2Land  Operations  Division,  DSTO 
Abstract 

The  engineering  of  complex  systems-of-systems  (SoS)  is  one  of  the  main  challenges  facing 
Defence  in  the  development,  acquisition  and  implementation  of  integrated  warfighting 
capabilities.  SoSs  are  ubiquitous  within  Defence,  yet  there  is  currently  little  effort  to  engineer 
these  systems  and  capabilities. 

This  presentation  explores  the  nature  of  SoS,  SoS  engineering  (SoSE)  and  the  potential  for 
MBSE  to  support  SoSE.  It  includes  a  discussion  of: 

1)  an  understanding  of  military  SoS  in  terms  of  its  variety,  formation,  evolution  and 
complexity; 

2)  an  understanding  of  SoS  activities  throughout  lifecycles  and  in  evolution; 

3)  potential  roles  of  MBSE  in  and  relation  to  SoSE  practice;  and 

4)  key  challenges  and  opportunities  for  applications  of  MBSE  for  defence  SoSE. 

Some  important  issues  and  features  of  SoS  are  explored,  including  military  SoS  variety, 
different  SoS  perspectives,  SoS  processes  and  SoS  complexity  and  well-being.  SoSE 
engineering  is  discussed,  addressing  the  difference  from  traditional  systems  engineering  and 
the  US  DoD  approach  to  SoSE.  Incorporating  MBSE  into  defence  SoSE  practice  is  shown  to  be 
a  necessary,  albeit  challenging,  step  in  developing  practical  approaches  to  SoSE.  This  will 
require  improvements  and  extensions  of  MBSE  concepts,  processes  and  tools  in  order  to 
adequately  and  successfully  address  SoS  challenges  and  issues. 
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modelling  and  design. 
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Overview 

What  are  SoSs? 

SoS  Engineering 

Potential  Role  of  MBSE  in  SoS  Engineering 

A  Challenge  for  MBSE 

Conclusion 
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DSTO 
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What  are  SoS? 


■  Civil 

•  Airport 

•  Transport  Network 

•  Mines 

■  Military 

•  Primary  focus  of  this  presentation 


Collection  of  heterogeneous  systems  that  work  together  to 
deliver  a  larger  scale  emergent  behaviour,  characterised  by: 


■  Operational  Independence  of  Elements 

■  Managerial  Independence  of  Elements 

■  Evolutionary  Development 

■  Geographical  Distribution  of  Elements 

■  Networks  of  Systems 

SoS  are  all  around  us 
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Examples  of  SoS  in  Defence 
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SoS  Variety  and  ’Weltanschauung’ 


Wide  variety  of  SoS  varying  with: 


■  Form,  function,  scale,  diversity,  rate  of  change  ... 

Defence  SoS  can  be  view  from  multiple  perspectives 

M7.V- Tactical Syuem  Anhitrrturr 


■  Platform  Based 

■  System  Based 

■  Capability  Based 

■  Force  Based 

■  Operational  Based 
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Interactions  between  SoS  Perspectives 


Interactions  between  the  SoS  perspectives 
■  Adding  to  overall  SoS  Complexity 


-  Capability -Based  SoS 


Systems-Based  SoS 


Force  Structure-Based 


Brigade-Based  SoS 


Company-Based  SoS 


Being  'part-or 

-  Being  "used-by'  (a  different  kind  of  ‘Part-oT) 
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Defence  SoS  Activity  Ontology  (under  development) 


Vfa. 


SoS  Management 


SoS  Context 


SoS  Engineering  Practice 


SoS  Design 


SoS  Analysis 


SoS 

Architectures 


Independency 


SoS  Integration 
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Processes 
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Traditional  SE  Process  Models 


Requirements 

Specification 


Systems  engineering  process  and  management 

■  mainly  for  top  down  systems  development 

■  theoretically  for  any  system 

■  However,  serious  problems  and  difficulties  in 
addressing  the  engineering  of  SoS 


Implementation 

(Construction/ 

Coding) 


Understat'd  User 
Requirements.  Develop 
System  Concept  and 
Validation  Ptan 
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SoSE  is  different  from  Traditional  SE 

SoSE  is  rarely  top  down  -  rather  middle  out 
SoS  can  be  either  new  or  existing 
■Often  enduring  capabilities 

■Overlay  an  ensemble  of  existing,  evolving,  and  new  systems 

SoS  managers,  when  designated: 

■Typically  do  not  control  all  the  requirements  or  funding  of  component  systems 
■can  only  influence 

SoSE  typically  focuses  on  the  evolution  of  capability  overtime 

Levels  of  SoSE  management  maturity: 

■Virtual 

■Collaborative  L  Most  Australian  Defence  SoS  are  at  this  level 

■Acknowledged  J 

■Directed  -  Seeking  to  increase  this  to  acknowledged 
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US  DoD  Approach  to  SoSE 


US  DoD  has  identified  7  Key  elements  of  SoSE: 

1 .  Translating  SoS  capability  objectives  into  high-level  SoS  requirements 

2.  Understanding  the  constituent  systems  and  their  relationships 

3.  Assessing  extent  to  which  SoS  performance  meets  capability  objectives 

4.  Developing,  evolving  and  maintaining  an  architecture  for  the  SoS 

5.  Monitoring  and  assessing  potential  impacts  of  changes  on  SoS  performance 

6.  Addressing  SoS  requirements  and  solution  options 

7.  Orchestrating  upgrades  to  SoS 


UNCLASSIFIED 

Managing  SoS  Complexity  and  Well  Being 

US  DoD  outlines  part  of  what  is  required 

Still  have  a  range  of  outstanding  challenges  for  SoSE 


Managing  the  Complexity  of  SoSE 

SoS  variety  and  relations 
Multiple  scales 

Unmanageable  documentation  based 
SE  processes  at  SoS  scale 
architecture  management 
Knowledge  management 
effective  orchestration  &  coordination 
accountability  management 
Nested  concepts  purposes 
Multidisciplinary  view  of  SoS 


Monitoring  the  Well  Being’  of  SoS 

■  Current 

■  Evolving 

■  From  multiple  perspectives  UNCLASSIFIED 
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MBSE and  SoSE 


Enabling 


SoS  Challenges  and  Requirements 
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SoS  Activity  Areas  with  MBSE  Potential 


SoS  Context 

SoS  Planning 

&  Decisions 

SoS  Activity 
Coordination 

Lifecycle 

Management 

SoS  Configuration 

Management 

SoS  Agreements 

SoS 

Methodologies 

SoS  Engineering  Practice 


SoS  Design 


SoS 

Architectures 


Change 

Management 


Uncertainty 

Management 


Disagreement 

Management 


Impact 

Management 


SoS 
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SoS  Evolution 
&  Adaptation 


SoS  Analysis 


Independency 


Information 


Emergent 

Behaviour 


SoS  Status 
and  Risks 
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Validation  and 
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Experimentation 


Simulation 
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SoS  Integration 


Processes 


Data  and 
Information 


Inter-Systems 


Human-Sys. 


SoS  Proto-type 
Testing 


Test  and 
Evaluation 


Future  MBSE  Roles 
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MBSE  Support  and  SoS  Perspectives 


Platform  Based  SoS 

■  Similar  to  standard  major  project  SE  use  of  MBSE 

■  “Imperial  projects”  taking  lead  for  major  elements  of  SoSE 

System  based  SoS 

■  Networking  /  Information  system  “glue”  projects 

•  Generally  Virtual  or  Collaborative  but  moving  to  Acknowledged  SoS 

■  MBSE  to  support  engineering  &  management  support  across  many  projects 

■  High  impact,  particularly  for  Joint  and  Land 

Capability  based  SoS 

■  CDG/DMO  SoS  and  service  based  SoS 

■  MBSE  to  support  SoS  synthesis  and  engineering  of  multiple  component  projects 

•  Managing  and  applying  lessons  learnt 

•  Generally  Virtual  or  Collaborative  SoS  management,  some  Acknowledged  SoS 

Force  based  SoS 


■  Potential  to  use  MBSE  to  support  force  design  trade-offs  (?) 

Operational  based  SoS 

■  Directed  SoS,  but  with  little  engineering  design 

•  Potential  to  use  MBSE  to  support  force  design  trade-offs 

■  MBSE  has  a  role  in  configuration  control  and  certification 

UNCLASSIFIED 


UNCLASSIFIED 


MBSE  Support  to  SoS  Complexity  Management 


Need  an  integrated  SoS  approach 

■  Cross  project  knowledge 

■  Managing  the  volume  of  data 

■  Common  methodology 

MBSE  provides  potential  to: 

■  Establish  SoS  standards  and  processes 

•  G  e  ne  r ate  co  n  s  iste  nt  co  mpo  n  e  nt  arte  facts 

•  Enable  synthesis  of  SoS  artefacts 

■  Manage  web  of  cross-project 

•  Interdependencies 

•  Agreements 

■  Support  SoS  design  trade-offs 

•  Central  tool  for  managing  each  ‘SoS  Wave’ 


■  Monitor  &  manage  SoS  status  and  Well  Being 


Manage  and  track  status  of  large  numbers  of  component  systems 
Understand  impact  of  changes  from  component  systems  on  SoS 
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Building  Upon  Exiting  Defence  SoS  Communities 


Defence  has  established  SoS  Capability  communities 
(but  currently  with  only  limited  examples  with  SoSE),  such  as: 

■  Joint  Fires 

■  Joint  ISR 

■  Amphibious 

■  Base  Protection 

■  Counter  IED’ 

■  Force  Networking  (Glue) 

•  Particularly  Tactical  Land 

Force  Networking 

Seek  to  build  on  these  communities 
and  add  the  missing  SoSE  component 


Complexity  necessitates  an  MBSE  based  approach 

■  Requires  development  of  MBSE  tools  and  stakeholder  education 


UNCLASSIFIED 


UNCLASSIFIED 

Challenge  for  MBSE  Community 

Build  the  MBSE  tools,  processes  &  practices  for  SoSE 


Start  applying  MBSE  to  key  SoS  test  cases: 

■  Amphibious  Capability 

■  Land  Force  Networking 

■  Certification  of  Operational  Forces 

Establish  a  partnership  with  capability 
development  community  for  SoSE 

■  Note  also  called  “capability  engineering” 

Time  is  right  to  address  SoSE 

■  Lessons  from  large  projects  have  grow 
the  need  for  capability  engineering 

■  Initiatives  in  CDG  -  DGICD  to  address 
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Conclusion 


SoS  present  a  major  challenge  for  Defence  engineering 

■  Complex,  with  a  large  number  of  component  systems 

■  Different  from  traditional  SE 

•  Often  enduring  systems  developed  in  ‘Waves’ 

■  Multiple  Perspectives  on  SoS 

Need  MBSE  in  order  to: 


■  Establish  SoS  standards  and  processes 

■  Manage  the  volume  of  SE  artefacts 

■  Manage  web  of  cross-project  Interdependencies  &  Agreements 

■  Support  SoS  design  for  each  ‘SoS  Wave’ 

■  Monitor  &  manage  SoS  status  and  Well  Being 

■  Understand  impact  of  changes  from  component  systems  on  SoS 


Window  of  opportunity  to  establish  a  MBSE  in  Defence  SoSE 
Initially  address  a  few  test  cases: 

■  Amphibious  Capability 

■  Land  Force  Networking 


Certification  of  Operational  Forces 
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14.  Model  Based  Systems  Engineering:  Issues  of 
application  to  Soft  Systems 


Ady  James,  Alan  Smith  and  Michael  Ernes 
UCL  Centre  for  Systems  Engineering,  Milliard  Space  Science  Laboratory 

Abstract 

Projects  often  seek  to  deliver  new  or  improved  capabilities  within  complex,  poorly  defined 
and  changing  contexts.  The  application  of  MBSE  under  such  circumstances  can  be  problematic 
and  in  this  paper  we  discuss  these  issues,  and  suggest  approaches  for  their  mitigation. 

A  particular  system  solution  might  be  envisaged  as  a  combination  of  subsystems  connected 
through  a  common  architecture.  Systems  thinking  suggests  that  given  clear  requirements  and 
a  solution  concept,  one  can  move  forward  through  the  definition  of  subsystem  capabilities 
and  the  system  architecture  -  where  MBSE  is  particularly  useful.  However,  in  many 
applications  the  degree  of  turbulence  or  evolution  within  the  requirements  that  can  be 
expected  means  that  close  human  intervention  is  necessary  to  keep  the  solution  fit  for 
purpose.  Moreover,  this  human  intervention  must  be  based  on  significant  experience  and 
domain  knowledge  so  as  to  cope  with  the  many  Soft  System  issues  that  are  likely  to  be 
present.  At  University  College  London  (UCL)  Centre  for  Systems  Engineering  we  propose  five 
principles  that  we  believe  should  underpin  all  SE  development  projects.  In  this  work  we 
discuss  these  principles  and  their  application  to  MBSE  within  a  Soft  System  context. 

The  UCLse  principles  are: 

•  Principles  govern  process 

•  Seek  alternative  systems  perspectives 

•  Understand  the  enterprise  context 

•  Integrate  systems  engineering  and  project  management 

•  Invest  in  the  early  stages  of  projects 

Moreover,  we  will  also  look  at  how  encapsulation  can  be  used  to  protect  MBSE  sub-system 
developments  from  the  likely  changes  in  scope  and  direction  of  the  overall  development. 
Encapsulation,  while  fundamental  to  an  object  oriented  approach,  is  much  less  well 
developed  for  soft  systems  projects  except  where  it  manifests  as  a  pragmatic  approach  taken 
by  the  systems  engineer,  systems  engineering  manager  or  project  manager.  Through  an 
encapsulation  approach  one  can  create  a  system  from  the  inside  out,  i.e.  begin  sub-system 
development  before  the  final  structure  of  the  overall  system  is  fully  defined.  There  are 
parallels  with  a  system-of-system  approach  in  which  the  sub-systems  pre-exist  the  system.  Re¬ 
use  and  the  use  of  Commercial-Off-The-Shelf  (COTS)  and  Military-Off-The-Shelf  (MOTS)  sub¬ 
systems  are  natural  to  an  encapsulated  approach. 

An  important  element  of  such  an  approach  is  the  validation  of  the  chosen  system  architecture 
or  an  estimation  of  its  resilience.  This  can  be  undertaken  through  a  carefully  selected  (and 
weighted)  set  of  scenarios  -  the  consequences  of  each  being  used  to  define  the  interface 
margins  and  architectural  capacity  within  the  overall  system.  This  is  a  natural  extension  to  the 
concept  of  requirements  volatility  found  in  requirements  management  tools  etc. 
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Finally  we  will  look  at  the  bounds  of  MBSE,  where  is  it  not  a  practical  way  forward  and  where 
should  it  be  supplemented  and  augmented  by  a  Soft  Systems  front  end  and  concurrent 
activity?  For  instance  some  system  capability  uplifts  are  dominated  by  the  viewpoints  of 
existing  participants  and  are  often  in  situations  where  there  is  no  single  design  authority. 
While  MBSE  can  improve  their  toolset,  the  actual  system  level  changes  that  are  possible  may 
lend  themselves  more  to  change  management  than  MBSE. 
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Model  Based  Systems  Engineering  - 
Issues  of  application  to  Soft  Systems 


Professor  Alan  Smith 
Dr  Adrian  James 
Dr  Michael  Ernes 
Centre  for  Systems  Engineering 
University  College  London,  UK 


But  what  is  MBSE? 

INCOSE  SE  Vision  2020  (INCOSE,  2007): 

“the  formalized  application  of  modelling  to  support  systems  requirements, 
design,  analysis,  verification  and  validation  activities  beginning  in  the 
conceptual  design  phase  and  continuing  throughout  development  and 
later  lifecycle  phases”. 

But  complex  system  development  without  modelling  is  unthinkable. 
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MBSE  for  soft  systems 

Let’s  avoid  a  debate  here  about  what  MBSE  is 
and  how  it  differs  from  ‘Conventional  SE’ 

Maybe  the  devil’s  in  the  ‘formal’  bit. 

•Instead  let’s  consider: 

-  Hard  and  Soft  Systems 

-  Application  of  UCL’s  principles  for  systems 
engineering 

-  Scenarios 

-  Encapsulation 


Hard  and  Soft  Systems 

Soft  system  element  (person  or  team) 
Hard  system  element 


Hard  system  element  with 
HCI 

Hard  System  requirements  come 
from  Soft  System  needs 


For  instance  a  capability  of  a  warship 
only  comes  about  when  you  add  the  crew 

Dealing  with  Soft  Systems  is  not  just  about 
HCI  or  Human  Factors  but  includes  such 
elements  as  buy-in,  legacy  thinking,  cultural 
change,  ... 


Hard  System 


Soft  System 
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UCL  Centre  for  Systems  Engineering 
Principles  of  Systems  Engineering 


Seek  alternative  Integrate  systems  engineering 

systems  perspectives  and  project  management 


Understand  the 
enterprise  context 


Invest  in  the  early 
stages  of  projects 

Principles  govern 
process 


Principle  1  -  Principles  govern  process 


When  adapting  a  generic  process 

to  a  particular  situation  the  individual 
must  first  understand  the  principles 
that  underpin  the  process. 

In  Soft  Systems  it  is  very  important  to 
understand  the  human  dimension. 
While  the  systems  development 
principles  will  be  common  to  Hard 
and  Soft,  the  application  will  not. 

For  instance  a  requirements  capture 
process  for  a  Hard  System  could  be 
very  different  to  that  of  a  Soft 
System.  Similarly  for  requirements 
validation  or  verification  etc. 


The  application  of  MBSE  to  Soft 
Systems  will  require  skilful 
application  by  the  system  engineer. 
Not  someone  with  a  tool  and  a 
handbook. 
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Principle  2  -  Seek  alternative 
systems  perspectives 


The  very  essence  of  Soft  Systems 
development  and  natural  to  Model  Based 
Structured  Analysis  and  Design 
Methodologies. 

MBSE  should  explore  a  range  of  systems 
perspectives,  viewpoints  or  abstractions 
to  enhance  understanding.  It  should  not 
be  confined  to  just  structure,  and 
behaviour  models. 

The  time  dimension  can  be  a  valuable 
source  of  insight. 

-  Not  just  operational  sequences  and 
timelines  but  also  heritage  (which  informs 
buy-in)  and  foresight 

Recognise  the  importance  of  overlapping 
hierarchies 

-  Elements  that  are  parts  of  more  than  one 
system  require  appropriate  management. 


rrr?w 

Principle  3  -  Understand  the  enterprise  context 


In  Soft  System  developments  the  separation 
between  the  system  and  its  environment  is 
often  fuzzy  while  in  MBSE  its  either 
technological  or  a  HCI/GUI. 

Taking  a  ‘Seven  Samurai’  approach  then  the 
Enterprise  is  just  an  other  system  (Soft)  within 
the  system  landscape. 

The  accommodation  of  Soft  System  often 
faces  many  diverse  constraints  from  the 
Super  System. 

In  Soft  Systems  lack  of  corporate  buy-in  and 
end  user  understanding  are  more  common 
causes  of  failure  than  technical  issues. 
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Principle  4  -  Integrate  Systems  Engineering  and 
Project  Management 


While  PM’s  tend  to  use  many 
simplistic  and  deterministic  tools 
(e.g.  Gantt  charts)  nevertheless  they 
are  dealing  with  an  essentially  Soft 
System  where  human  management 
is  necessary. 

Systems  Engineers  work  with 
relatively  deterministic  tools  and 
processes. 

Everyone  is  seeking  models  that  are 
understandable  and  useful 
The  efficacy  and  efficiency  of  such 
models  in  Soft  System  developments 
are  likely  to  be  quite  different  to  that 
of  Hard  Systems  developments. 


UCL 

Principle  5  -  Invest  in  the  Resource 

Typical 

early  stages  of  projects 

Left  -  shifted  profile 

•  For  any  activity  in  a  project  there  will 

/\  f  \ 

be  a  correct  time  to  undertake  it. 

4mm\\  \ 

-  Too  early  wastes  resources  while  too  late 

/  ^  /  \ 

can  lead  to  downstream  adverse  impacts. 

/  y  \  \ 

•  The  optimum  ordering  of  activities 

should  be  identified,  resisting 

Time 

pressure  to  defer  work  until  later  for 

short-term  reasons. 

Soft  System 

front  end 

•  A  Soft  System  front  end  which 

creates  a  more  stable  requirement 

set  could  be  a  good  investment  for 

many  developments  which  are, 

eventually,  suitable  for  a  more  formal 

MBSE  approach. 
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Soft  System  Front  End 


11 


Agile? 

•  Agile  accommodates  many  of  the  issues  typically  found  in  Soft 
Systems  (such  as  evolving  needs  and  stakeholder  requirements) 
through  an  iterative  and  rapid  lifecycle  that  includes  user  feedback. 

•  However,  is  Agile  something  that  makes  up  for  the  absence  of  an 
effective  Soft  System  front  end? 

•  Should  Agile  be  adapted  to  be  more  'left  shifted’,  in  which  much  of  the 
requirements  evolution  is  dealt  with  up  front. 
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Scenarios  Planning  /  Requirements  Validation 


In  Soft  System  project 
stakeholder  requirements  are 
likely  to  evolve  during  the 
development  of  the  systems 
and  after. 

The  baseline  requirements  set 
must  somehow  anticipate 
these  changes 
Through  the  use  of  scenario 
planning  these  requirements 
can  be  tested  for  robustness 

MBSE  projects  with  significant 
soft  system  aspects  should 
engage  in  scenario  planning 
as  part  of  requirements 
definition  and  validation. 


key  force  2 


Scenario  A 
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Encapsulation 

•  Soft  system  elements  may 
begin  as  very  well  defined 
structures 
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Encapsulation 

♦  But  they  have  a  habit  of 
evolving  in  an  uncontrolled 
way 


15 
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Encapsulation 


This  makes  for  downstream 
incompatibility 
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Encapsulation 

♦  However  if  you  surround 
your  systems  elements 
within  a  standard 
interface 


17 


UCL 


Encapsulation 

♦  Their  integration  is 
more  assured 

♦  They  are  more  easily 
tested 
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Encapsulation 

♦  And  they  will  continue 
to  be  integrated  even 
as  they  evolve 

•  Scenario  Planning 
can  inform  the 
'thickness’  of  the 
encapsulation. 


19 
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Encapsulation 

•  After  all  a  systems 
architect  is  mainly 
interested  in  what’s 
inside  the  elements, 
only  what  the 
element  does. 
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Encapsulation 

♦  Soft  Systems  Encapsulation  is  another  left-shifted  activity. 

•  It  includes: 

-  Robust  organisational  structures 

•  E.g.  robust  against  corporate  reorganisation 

-  Robust  cultures 

•  Taking  advantage  of  a  human  characteristic,  albeit  at  the  risk  of  downstream  inflexibility 

-  Robust  job  descriptions 

•  Titles  reflect  the  role,  e.g.  ‘Systems  Engineer’ 

-  Robust  tool  sets 

•  That  do  not  change  with  every  upgrade 
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Conclusions 

•  Hard  and  Soft  systems  are  related.  Often  the  Hard  Systems 
requirements  have  their  origins  in  a  Soft  System. 

•  Soft  Systems  developments  use  models  too,  only  different  models. 

•  A  hybrid  lifecycle  could  be  imagined  with  a  Soft  System  front  end. 

•  If  we  are  to  imagine  a  hybrid  lifecycle  we  need  better  front  end  tools. 

•  E.g.: 

-  Rich  Picture  analysis  tools  that  create  influence  diagrams,  entity 
relationship  diagrams  etc. 

-  Scenario  Planning  tools  that  can  be  used  to  validate  Soft  Systems 
requirements 

•  Of  course  it  would  be  nice  to  know  what  MBSE  really  is. 
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15.  Best  of  Both  Worlds:  CORE-based  WS  AF  with 
DOORS-based  Requirements  Management 

1  2 

Roger  McCowan  and  Michael  Waite 
1  2 
MHW  Holistic  Solutions  and  Aerospace  Concepts 


Abstract 

The  Whole-of-Systems  Analytical  Framework  (WSAF)  has  been  developed  at  DSTO  with 
personnel  from  both  Weapons  Systems  Division  (WSD)  and  Aerospace  Concepts  Pty  Ltd.  It  is 
based  on  Vitech  CORE®  and  has  evolved  and  matured  through  use  on  several  projects  and 
proved  its  worth  as  an  MBSE  capability  environment.  Despite  the  successes  of  the  WSAF  and 
the  functionality  within  CORE®  to  support  requirements  management.  Defence  policy 
currently  remains  that  IBM®  Rational®  DOORS®  is  mandatory  for  the  requirements 
management  on  all  ACAT  I  and  ACAT  II  projects.  Because  of  the  Defence  Materiel 
Organisation's  (DMO)  current  investment  in  DOORS®  (licences  and  number  of  people  trained 
in  its  use,  etc.)  this  situation  is  unlikely  to  change  for  some  time. 

This  paper  provides  an  overview  of  the  means  by  which  the  capability  modelling  can  be  done 
using  the  WSAF  to  maintain  model  integrity  whilst  allowing  projects  to  perform  the  ongoing 
management  of  requirements  using  DOORS®.  The  approach  was  developed  and  refined 
during  the  definition  of  the  Land  Combat  Vehicle  System  (Defence  Project  LAND400),  where 
the  Operational  Concept  Document  had  been  developed  using  the  WSAF,  and  three  Function 
and  Performance  Specifications  (FPSs)  covering  nine  vehicle  variants  needed  to  be  produced 
using  the  WSAF  but  with  the  requirements  transferred  into  DOORS®  for  use  by  the  DMO 
project  office. 

In  order  to  maintain  consistency  between  the  two  databases  a  strict  data  management  scheme 
was  developed,  including  the  definition  of  the  data  interface.  One  of  the  greatest  challenges  of 
this  was  to  understand  and  overcome  the  different  implementations  of  data  attributes  and 
relationships  used  in  CORE®  and  DOORS®.  Amongst  the  variety  of  information  transferred 
through  this  interface  was  the  unique  identifier  assigned  in  both  software  tools  to  ensure  data 
veracity.  Although  many  of  the  requirements  were  common  across  both  the  three  main 
vehicle  types  and  the  nine  vehicle  variants,  there  were  others  which  were  unique  to  particular 
variants.  This  highlighted  the  strength  of  the  model-based  approach,  where  it  was  possible  to 
update  the  detail  of  one  requirement,  which  would  be  reported  in  all  relevant  specifications. 

While  the  process  developed  and  implemented  still  required  manual  "post-processing"  of 
some  of  the  data  (mostly  resulting  from  the  differing  character  sets  for  hard  returns,  non¬ 
breaking  spaces  and  special  characters  e.g.  °,  ±,  etc),  this  work  proved  that  the  systems 
engineer  really  can  have  the  "best  of  both  worlds"  -  the  strength  of  rich,  model-based 
information  architecture  from  CORE®  and  the  benefit  of  rigorous  requirements  management 
from  DOORS®. 

This  presentation  will  provide  insight  into  the  CORE®  to  DOORS®  interface  developed,  the 
challenges  faced  and  advice  to  personnel  engaged  on  major  capital  equipment  projects  -  in 
particular,  they  should  not  use  the  mandated  policy  of  DOORS-based  requirements 
management  as  an  excuse  to  not  use  the  WSAF  to  do  capability  modelling. 
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Overview  of  Presentation 

•  Project  Context 

•  Approach 

-  Strict  data  management  scheme 

•  Interface 

•  Challenges 

•  Method/Process 

•  Conclusion 

•  Q& A 


Project  Context 

•  Land  Combat  Vehicle  System  (LAND400) 

-  OCD  developed  during  2011  using  WSAF 

-  DMOSS  Contract  in  2012  to  develop  three  FPSs 

covering  nine  vehicle  variants 

-  FPS  requirements  to  be  in  DOORS®  as  per  DMO 

policy 

-  DMO  Project  Office/LEA  provided  SME  and  drafted 

many  of  the  requirements  using  Excel 
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Approach 


Interface  (1) 


Single  CSV  file,  exported  from  CORE® 

Fields 

-  Vehicle  Variant  (Defined  list,  multi-valued) 

-  DOORS  Requirement  ID 

-  CORE  Object  ID 

-  Requirement  Text 

-  Requirement  Priority  (Defined  list) 

(continued  on  next  Slide) 
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Interface  (2) 


Challenges 

•  Requirement  Text  copied  from  Excel  cells  contained 
embedded  line  feed  codes  (char(10)),  as  well  as  non¬ 
breaking  spaces 

•  CSV  exported  from  CORE  loses  diagrams  and 
formatting  information  (superscript,  bold,  etc.) 

•  DOORS  importation  of  CSV  file  could  not  handle 
special  characters  (e.g  ±,  smart-quotes,  and  non¬ 
breaking  spaces) 

•  Attribute  Definitions  -  mismatches  will  cause 
importation  to  fail 
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Method/Process  (1) 

•  Export  requirements  with  all  relevant  attributes  from 
CORE,  into  a  CSV  file 

•  Use  Excel  on  the  resulting  CSV  file  to  substitute 
spaces  for  line-feed  codes 

•  Use  Excel  to  create  a  new  column  which  combines 
the  Heading  Number  and  the  Heading  Title 

5j  •  Use  Word  to  find  and  replace  all  special  characters 

•  Save  as  CSV,  then  insert  hard  return  between  every 
record,  then  save  as  TXT 


Method/Process  (2) 

•  Create  the  DOORS  Requirements  Module,  with  all 
attributes  and  attribute  definitions 

•  Use  DOORS  to  import  the  TXT  file,  which  creates 
the  structured  requirements  set 

•  Export  just  the  DOORS  Requirement  ID  attribute 
into  a  CSV  file 

•  Merge  the  ReqlD  file  with  the  updated  CSV  file 

•  Import  the  merged  CSV  file  into  DOORS  to  update 
all  requirements  with  their  attributes 
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Method/Process  (3) 

•  In  DOORS,  perform  find/replace  on  special 
characters 

•  Perform  manual  update  of  text  with  superscripts 

•  Insert  diagrams  and  figures  at  appropriate  places  and 
levels 

•  Export  CSV  file  from  DOORS  to  update  CORE 
with  DOORS  ReqlDs 


Conclusions 

•  The  process  steps  described  took  about  one  hour,  on 
a  requirement  set  of  about  1800  requirements 

•  The  WSAF  CORE  model  remains  the  “Source  of 
Truth”  at  all  times,  therefore  changes  are  NOT  made 
to  the  DOORS  requirement  objects 

•  Revisions  are  best  done  by  replacing  the  DOORS 
requirement  module,  rather  than  updating  attributes 

•  CORE®-based  WSAF  and  DOORS®-based 
Requirements  Management  is  simple  and  viable 
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Abstract 

MBSE  tools  and  techniques  in  a  broad  sense  provide  a  structured  approach  to  developing 
conceptual  models  of  complex  systems.  Key  features  of  these  approaches  are:  the  use  of 
graphical  based  views  on  a  central  model  that  reflect  the  interests  of  particular  stakeholders  in 
the  system;  hierarchical  decomposition  of  the  system  in  question;  and  an  ability  to  add,  over 
time,  increasing  levels  of  detail  to  the  model  as  knowledge  is  acquired,  or  in  other  words 
allow  the  model  to  move  from  the  abstract  towards  the  formal  without  the  need  to  redefine 
the  model  in  a  different  modelling  environment.  Through  such  an  approach  the  leap  of  faith 
required  to  transition  from  model  to  real  system  is  reduced  when  compared  to  traditional 
techniques. 

When  the  real  world  system  is  software  it  is  possible  to  take  the  conceptual  modelling 
methodologies  all  the  way  to  a  formal  (in  the  mathematical  sense)  specification  such  that 
ultimately  the  model  has  a  one  to  one  mapping  with  the  real  software  system.  Indeed  great 
strides  have  been  made  with  modelling  methodologies  and  tools  in  the  software  domain,  for 
example  with  UML. 

Systems  Engineering  of  course  has  to  deal  with  complex  application  domains  well  beyond  just 
software,  where  any  model  of  the  system  will  always  be  conceptual  at  some  level  because  a 
one  to  one  mapping  with  the  real  system  will  never  exist.  SysML  is  an  extension  and 
modification  of  UML  that  aims  to  support  the  broader  modelling  needs  of  SE,  hence  the  term 
MBSE.  However,  engineering  has  at  its  disposal  another  type  of  modelling  that  is  simulation, 
which  can  provide  great  insights  into  the  behaviour  of  complex  systems.  Although  UML  and 
SysML  primarily  support  conceptual  modelling  they  do  have  enough  formality  in  them  to 
support  certain  types  of  simulation  (after  all  computer  based  simulations  are  in  themselves 
software  systems),  for  example  in  some  behavioural  graphical  views,  such  as  activity  and  state 
machine  diagrams.  The  algorithmic  model  of  computation  used  with  these  is  basically 
Discrete  Event  Simulation  (DEVS)  such  that  the  transitions  between  activities  or  state 
represent  discrete  events  in  time.  Although  many  systems  can  adequately  be  simulated  with 
discrete  events  (in  time)  many  more  need  more  powerful  models  of  computation  such  as 
discrete  time  and  Ordinary  Differential  Equation  (ODE)  solving,  which  although  can  be 
expressed  in  the  DEVS  formalisms  are  generally  only  realised  in  specialised  engineering  level, 
graphical  based,  modelling  and  simulation  tools  such  as  Simulink®.  Such  tools  are  built 
principally  first  and  foremost  to  create  formal  models  in  a  bottom  up  approach  and  thus  lack 
features  to  support  for  conceptual  modelling. 

Interestingly  the  diagrams  used  in  specialised  engineering  M&S  tools  often  have  the 
appearance  of  structural  models.  This  is  because  they  are  actually  graphical  representations  of 
mathematical  algorithms,  more  precisely  iterative  algorithms.  The  challenge  therefore  for 
MBSE  is  to  develop  general  purpose  graphical  modelling  views  that  transition  naturally  from 


174 


UNCLASSIFIED 


UNCLASSIFIED 

DSTO-GD-0734 

system  relevant  decomposition  views  into  views  of  iterative  algorithms  capable  of  being 
executed  with  potentially  any  iterative  model  of  computation. 

This  paper  outlines  a  graphical  modelling  view  similar  to  the  internal  block  diagram  of  SysML 
that  supports  hierarchical  decomposition  and  iterative  algorithmic  expression  at  the  same 
time. 
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Background:  Modelling  builds  knowledge 
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Background:  Different  modelling  approaches 
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MBSE  Approach  to  modelling  behaviour 


Questions  are  around  when 
the  events  occur. 


What  about  questions  of  a 
non-temporal  nature? 

Either  way  it  may  be 
necessary  to  simulate  the 
continuous-time  behaviour 
of  the  system. 


The  main  elements  represent  constant  behaviour  for  a  period  of  time. 
Connections  represent  instantaneous  transitions  between  different  constant 
behaviours. 

This  lends  itself  to  simulating  sequences  of  discrete  events  in  time. 
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MBSE  Approach  to  modelling  algorithm  structure 
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Summary  of  Goals 


•  Seamless  transition  from  systems  decomposition 
to  algorithm  decomposition. 

•  Both  are  structural  views. 

•  Means  of  integrating  multiple  Models  of 
Computation  (MoC): 

•  Discrete  Event; 

•  Discrete  Time; 

•  ODE  solving; 

•  etc 

•  Means  of  encapsulating  MoC  within  branches  of  a 
model  decomposition  (MoC  within  MoC). 
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Underpinning  M&S  Theory 
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Mathematical  Algorithms  for  Simulation 


•  Functions  can  be  decomposed. 
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Mathematical  Algorithms  for  Simulation 

•  Algorithm  iterations  can  be  nested. 
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Some  Definitions 


•  A  Function  is  a  arbitrary  collection  of  mathematics  that  can 
only  be  executed  once  all  its  input  Variables  have  been 
properly  updated  in  the  context  of  the  current  iteration. 

•  A  Variable  is  an  arbitrary  complex  data  structure  that,  within 
the  context  of  an  iteration,  is  updated  and  read  by  Functions. 

•  A  Model  of  Computation  is  a  set  of  rules  regarding  the 
execution  and  management  of  user  declared  Functions  and 
Variables,  and  is  implemented  by  an  Iteration  Controller. 
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Iterative  Algorithms 


Function  C 


Update 


Function  A 

Pre-update  Read 

Post- update  Read 

Function  B 

* 

Variable 

In  the  context  of  an  iteration: 

■  Functions  that  read  from  a  variable  pre-update  must  be 
executed  before  it  is  updated. 

■  Functions  that  read  from  a  variable  post-update  must  be 
executed  after  it  is  updated. 
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Specification 


•  Models  are  defined  by: 

*  An  interface,  which  consists  of  any  number  of  Input  and/or 
Output  Ports. 

•  An  internal  definition  consisting  of  any  number  of 
Functions,  Shared  Variables,  Attributes,  or  interfaces  of 
Child  Models. 

♦  Relationships  between  Functions  and  Variables  (including 
Ports  of  child  Models). 

•  Zero  or  One  Iteration  Controller. 
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Specification 


•  Update  Relationship 


•  The  source  end  must  connect  to  a  Function.  The  target 
end  must  connect  to  either  a  Shared  Variable,  parent 
Model’s  Output  Port,  or  a  child  Model’s  Input  Port. 


•  Read  post-update  Relationship 

•  The  target  end  must  connect  to  a  Function.  The  source 
end  must  connect  to  either  a  Shared  Variable  or  Port. 


•  Read  pre-update  Relationship 

*  The  target  end  must  connect  to  a  Function.  The  source 
end  must  connect  to  either  a  Shared  Variable  or  Port. 
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Specification 


•  Iteration  Controller 


•  Embodies  a  specific  Model  of  Computation. 

*  Coordinates  the  execution  of  a  set  of  Functions  within  the 
Model  in  which  it  is  declared  according  to  relationships 
between  Functions  and  Variables  and  specific  MoC  rules. 

•  Selection  of  the  set  of  Functions  depends  on  the 
specific  1C. 

•  A  Function  dependent  on  a  MoC  cannot  be  executed 
under  another  MoC. 


♦  An  1C  must  itself  be  expressed  as  one  or  more  Functions 
that  can  be  executed  by  a  parent  1C. 
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Elements  supporting  DT  MoC 


ft]  Time  Variable 

0  Time  Request  Variable 
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Elements  supporting  ODE  Solver  MoC 
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Drawing  the  line  between  in-built  MoC  and 
User  defined  Model  constructs 

•  There  are  many  subtle  algorithmic  design  patterns  that  if  not 
built  into  an  MoC  must  (if  needed)  be  implemented  by  the 
modeller.  Most  are  not  particularly  universal  in  application. 

•  Specific  Function  triggering  (over  and  above  MoC  dependencies): 

•  Input  Variable  update; 

•  Time  =  Tau  (in  DT  MoC). 

•  Function  or  Model  enabling/disabling. 

•  Automatic  clearing  of  data  from  variables  between  iterations. 
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17.  Towards  the  Use  of  Network  Analysis  Method  In 
Analysing  Node  Properties  In  A  System  Model 


Li  Jiang  and  Hossein  Seif  Zadeh 
Joint  Operation  Division,  DSTO 


Abstract 


Model-based  system  engineering  methodologies  advocate  using  system  models  as  the  main 
vehicle  in  system  engineering  processes12.  In  this  methodology,  a  system  model  represents  the 
relationships  and  interaction  between  the  entities  being  modelled.  Figure  2  depicts  an 
example  of  such  abstraction  of  the  interaction  within  and  between  two  subsystems. 


(a)  The  first  component  network 


(b)  The  second  component  network 


Legend:  Filled  circles  represent  actors  or  agents 

Filled  diamonds  represents  use  cases  or  components 

Different  colours  are  used  to  distinguish  actors  (agents)  or  use  cases 

(components)  in  each  subsystem. 

Figure  2  A  sample  component  network  of  two  subsystems 


As  a  result  of  the  difficulty  in  understanding  complex  relationships  within  comprehensive 
systems  models,  there  is  a  need  for  a  systematic  approach  in  assessing  properties  of  such 
models13. 


12  Estefan,  J.  (2008).  Survey  of  model-based  systems  engineering  (MBSE)  methodologies.  Pasadena,  California. 
USA,  Jet  Propulsion  Laboratory,  California  Institute  of  Technology 

13  Brooks,  R.  J.  and  A.  M.  Tobias  (1996).  Choosing  the  Best  Model:  Level  of  Detail,  Complexity ,  &  Model 
Performance ,  Mathematical  and  Computer  Modelling,  Volume  24,  Number  4,  August  1996  ,  ppl-14 
testing 


UNCLASSIFIED 


193 


UNCLASSIFIED 

DSTO-GD-0734 

Lacking  evaluation  mechanism  for  system  models  presents  three  major  problems: 

(1)  difficulty  in  understanding  fundamental  properties  of  the  model  which  are  often 
attributed  as  a  major  reason  for  failure  of  the  system; 

(2)  lack  of  a  systematic  and  efficient  mechanism  in  ensuring  consistency  of  the  model 
through  all  stages  of  process,  system,  and  product  development14;  and 

(3)  difficulty  in  understanding  which  components  perform  critical  functions,  and  which 
components  serve  as  a  bridge  between  sub-systems. 

This  paper  presents  a  two-step  approach  in  assessing  properties  and  consistency  of  the  model. 
The  definitions  of  the  properties  and  consistency  are  briefly  discussed  below: 

•  Properties  are  defined  based  on  a  set  of  network  science  measures15.  To  use  the 
network  science  measures,  the  relationships  between  entities  in  the  system  model  are 
represented  as  an  entity  network  (see  Figure  1  for  a  simple  example).  The  network 
measures  can  be  computed  and  the  results  of  the  computation  can  be  explained 
meaningfully  within  the  system  engineering  discipline. 

•  Consistency  refers  to  the  congruent  between  entities  or  artefacts  developed  in  the 
system  development  process.  These  measures  can  be  quantitative  or  qualitative. 

Jiang  et  al16  have  shown  that,  in  the  context  of  software  development,  analysing  properties  of 
a  model  provides  meaningful  feedback  for  the  purpose  of  design  and  system  verification 
processes. 

The  proposed  approach  provides  a  practical  mechanism  for  analysing  properties  of  the 
system.  The  major  contribution  of  this  work  is  two  folds: 

(1)  properties  of  system  models  can  be  used  at  both  network  and  node  level,  containing 
critical  information  on  the  overall  entity  network,  and 

(2)  consistency-assessment  measures  provide  a  mechanism  to  verify  consistency  of  the 
system  model. 

The  implication  and  significance  of  using  properties  of  nodes  within  the  context  of  system 
engineering  are  also  discussed. 


14  Van  Der  Straeten,  R.,  T.  Mens,  et  al.  (2003).  Using  description  logic  to  maintain  consistency  between  UML 
models.  «UML»  2003-The  Unified  Modeling  Language.  Modeling  Languages  and  Applications:  326-340. 

15  Wasserman,  S.  and  K.  Faust  (1995).  Social  Network  Analysis:  Methods  and  Applications.  Cambridge, 
University  of  Cambridge  Press 

16  Jiang,  L.,  K.  M.  Carley,  et  al.  (2012).  The  Impact  of  Component  Interconnections  On  Software  Quality:  A 
Network  Analysis  Approach.  The  2012  IEEE  International  Conference  on  Systems,  Man,  and  Cybernetics 
(IEEE  SMC  2012) 
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Introduction 

Model-based  system  engineering  (MBSE) 

♦♦♦  MBSE  is  the  formalized  application  of  modelling 
to  support  system  requirements,  design,  analysis, 
verification  and  validation  activities  in  the  system 
engineering  life  cycle. 

□  Requirements  Models  -  Requirement  Diagram 

□  Design  Models  -  Package  Diagram,  Sequence  Diagram, 
Activity  Diagram,  State  Machine  Diagram,  etc. 


C  «•»-»> - 

-h- 

Jr 

-’'Vs. 

Sr, 

( Tmksr  ) 

Unclassified 


Introduction 

Compute  the 
consistency 

Identify  the 
properties 

Application  to 
the  system 
integration 

Conclusion 


Introduction  (Cont'd) 

*1*  Problems 

O  Hard  to  ensure  the  consistency  between  the  designs  and 


evolutions  of  design. 

O  Hard  to  identify  the  critical  elements  (nodes)  in  the  system 
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Introduction 

Introduction  (Cont'd) 

Compute  the 
consistency 

♦♦♦  How  to  verify  and  evaluate  the  system  models 
remains  challenges  in  both  industry  and  academia 

□  Status  quo  in  industry  practices 

Identify  the 
properties 

□  Research  -  major  focus  on  mathematical  approaches 
>  model-checking  and  automated  theorem  proving 

Application  to 
the  system 
integration 

>  using  description  logic  to  maintain  consistency 

♦♦♦  Lacking  evaluation  and/or  verification  mechanism 
for  system  models  presents  three  major  problems 

Conclusion 

1 )  lack  of  a  systematic  and  efficient  mechanism  in  ensuring 
consistency  of  the  model 

2)  difficulty  in  understanding  which  components  perform 
critical  functions 

3)  difficulty  in  understanding  fundamental  properties  of  the 
model 
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Introduction 

The  Proposed  Approach 

The  Proposed 
Approach 

♦>  An  approach  is  proposed  for  verification  and 
evaluation  of  the  models. 

Compute  the 
consistency 

The  approach  include  two  parts: 

(1 )  Define  a  set  of  measures  to  compute  the  consistency 
between  the  models. 

Identify  the 
properties 

(2)  Using  several  network  measures  to  identify  the  properties 
of  the  elements  in  the  model. 

>  Compute  the  complexity  of  the  model 

Application  to 
the  system 
integration 

>  Compute  the  properties  of  the  elements  in  the 
model. 

Conclusion 
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The  Proposed  Approach  (Cont'd) 

Introduction 


The  Proposed 
Approach 

Compute  the 
consistency 

Identify  the 
properties 


Application  to 
the  system 
integration 


♦♦♦  Assumption  with  the  approach: 

□  The  system  design  following  the  system  engineering 
process  and  SysML  (or  UML)  are  used  in  the  design. 

□  The  relationships  between  the  requirements,  objects, 
components  or  package  of  the  system  in  the  system 
models  are  well-established. 

□  Targeting  on  the  project  covering  the  entire  system 
development  lifecycle. 

❖  The  applicability  of  the  approach  to  the  system 
integration  is  briefly  discussed  at  the  end  of  the 
presentation. 


Conclusion 
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Part  1 :  Compute  The  Consistency 
Between  The  Models 

The  Proposed 

Step  1 :  Define  a  set  of  measures 

Approach 

□  The  measures  are  divided  into  following  classes 

>  Quantity  metrics 

Compute  the 
consistency 

■  counts  of  the  design  entities  and  relationships. 

Identify  the 
properties 

y  Complexity  metrics 

■  measure  the  relations  between  design  entities  and  the 

structure  of  the  proposed  system  architecture. 

Application  to 

y  Quality  metrics 

■  measure  the  relationship  between  the  desired  and  the  actual 

the  system 

characteristics  of  the  architecture. 
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Conclusion 
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♦♦♦  Examples  of  the  proposed  quantity  metrics  for 

evaluation  of  the  models 

Compute  the 

□  Number  of  Diagrams 

y  Package  Diagrams,  Use  Case  Diagrams,  Sequence 

consistency 

Diagrams,  State  Diagrams,  Activity  Diagrams, 

Identify'  the 

Requirements  Diagram,  Class  Diagram 
□  Number  of  entities 

properties 

y  Requirements,  Use  Cases,  Actors,  Activities,  Package 

Application  to 

□  Number  of  design  relationship  type 

the  system 

>  Links  between  entities.  Interactions,  Activity  Flows, 

integration 

State  Transitions. 

Conclusion 

Unclassified 

Unclassified 


Part  1 :  Compute  The  Consistency 
Introduction  Between  The  Models  (Cont’d) 


The  Proposed 
Approach 

Compute  the 
consistency 

Identify  the 
properties 


♦♦♦  Examples  of  the  proposed  complexity  metrics 


OverallDesignComplexity  =  1  - 


NoDesignEntities 
NoRelationships  +  No  Actors 


UseCase  Complexity  =  1  - 


NoUseCase 

NoRelationships  +  NoActors 
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Object  Iriteration  Complexity  = 


NoofObject  NoofClasses 

N  oofObj  e  ctlnter  ac  ti  on  N  o_of_C  1  as  s_ As  s  o  c  i  ati  on 
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Step  2:  Understand  the  links  and  traceability  between 
the  models 


*  Objects  map  to  objects 

*  Classes  map  to  classes, 

*  Messages  map  to  the  links 
between  objects  or  classes) 


State  Diagram 


S  e  que  nc  e  D  i  agram 
TIT- 


Realised  >y 


complemented  by 


ClassDiagram 


Aggregated  to 


Block 

Diagram 

UseC 

!)ases 

Package  Diagram 

ilities”  requir  rents  maps  to 


Other  System 
Design 
Consideration  I 


System  architecture 

Hardware  (such  as  safety  and  reliability) 
Network  (such  as,  cable,  hub,  structure,  security) 
Operation  iy$&&$y$oflware 
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Step  3 :  Define  a  set  of  consistency  measures 


^  t  No  Require metnsRealisedByUseCases 

DegreeOfConsistencyreq_useca*  — - 

NoRequirements 


DegreeOfConsistencyuSecase_s<qD  = 


NoUseCasesModelledBySequenceDiagram 

NoUseCases 


DegreeOfCo  nsistencyseqD  ClassDiagram  — 

No_Classes  InClassDiagram  +  NoObjectsInObjectDi  agram 
NoClasses  InSequenceDiagram  +  NoObjects  InSequenceDiagram 


DegreeOfConsistencyciasses_  methods  — 

^  NoUndefinedMethodsReferences  +  NoUnderfinedParameterReferences 

No  DefinedMethods  +  No  DefinedParameters 
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The  Proposed  ( 

I^ase  Study  1 :  Compute  the  consistency  between  the  models 

Approach 

□  Data  Sources:  Student  Group’s  Design  Documents: 

□  Information  about  the  students: 

Compute  the 
consistency 

> 

Year  3  students  from  computer  science,  math  and  other 
engineering  program. 

Identify'  the 
properties 

> 

Students  are  involved  in  Group  Project  with  5  to  6  group 
members. 

> 

Intensive  one  term -long  project  supervised  by  lecturers 

Application  to 
the  system 
integration 

> 

The  project  is  about  developing  a  robot  that  can  detect  mines  in 
the  “battle  field” 

> 

Students  are  guided  through  the  entire  engineering  process  from 
requirements  gathering  to  the  final  deliverables 

Conclusion 

> 

Students  uses  various  engineering  process  models 

> 

SRS,  SDD,  SPMP  are  compulsory  dehverables  and  presented 
during  the  processes  of  the  project 
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Part  1 :  Compute  The  Consistency 
Between  The  Models  (Cont'd) 

Case  Study  1 :  Compute  the  consistency  between  the  models 

□  Data  Sources:  Student  Group’s  Design  Documents: 

□  Information  about  the  students: 

□  Results 


Group  1 
(2010) 

Group  15 
(2010) 

Group  5 
(2011) 

Group  4 
(2011) 

DegreeOfConsistency  (Requirements 
and  Usecases) 

0.72 

0.83 

0.88 

0.69 

DegreeOfConsistency  (Usecases  and 
SequenceDiagram) 

0.60 

0.58 

0.83 

0.80 

DegreeOfConsistency  ( 
SequenceDiagram  and  Class  Digram) 

0.93 

0.57 

0.79 

0.49 

Overall  Consistency 

0.40 

0.27 

0.58 

0.27 

[Average 

0.78 

0.69 

0.84 

0.67 
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Network  Analysis  Techniques 
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—  Validation 
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Approach 

♦♦♦  Examples  of  network  measures  used 
□  Network  level 

Compute  the 
consistency 

>  Network  Size,  Link  coimt.  Density,  Isolate  count 
(Component  count ),  Clustering  coefficient 

□  Node  level 

Identify  the 
properties 

y  Degree  centrality.  Betweenness  centrality. 

Eigenvector  centrality,  Closeness  centrality 

Application  to 
the  system 
integration 

♦v*  Network  analysis  techniques  used 

□  Visualisation 

□  Computation  analysis 

□  Statistical  analysis 

Conclusion 
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Part  2:  Identify  the  properties  of 
the  elements  in  the  models  (Cont’d) 

♦♦♦  Case  study  2 

□  Analyse  the  critical  nodes  in  the  two  use  case  diagrams 
for  two  subsystems  for  an  industry  project. 


Compute  the 
consistency 


Identify  the 
properties 

Application  to 
the  system 
integration 

Conclusion 

Note:  Filled-eircles  represent  actors  or  agents  and  fUled-diamonds 
represents  use  casesUnclassified 
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Part  2:  Identify  the  properties  of  the 
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♦>  Case  study  2 

□  Analyse  the  critical  nodes  in  the  two  use  case  diagrams 
for  two  subsystems  for  an  industry  project. 

□  Compute  the  measures 

□  Analysis  the  results 


Rank 


Total 

degree 

centrality 


Subl  A  2 


Subl  A  1 


Sub2  A  1 


Subl  A  3 


Subl_UC 

8 


I6nc  SubaiAL2 


Betweenness 

centrality 


Sub2  A  1 


Sub2  A  2 


Sub2  UC  5 


Subl  UC  8 


Sub2  UC  3 


Sub2  UC  7 


Closeness 

centrality 


Subl  A  2 


Subl  A  4 


Subl  A  1 


Sub2  A  1 


Sub2  A  2 


Subl  A  3 


Eigenvectoi 

centrality 


Sub2  UC  5 


Sub2  A  2 


Sub2  A  1 


Sub2  A  3 


Sub2  UC  9 


Sub2  UC  1 
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Approach 

□  Project  actual  results  obtained  from  programmers  and 
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testing  engineers 

>  Following  use  cases  took  more  time  to  implement  than 

Identify'  the 

other  nodes: 

Subl  A  2,  Subl  A  1,  Sub2  A  1  ,  Subl  A  3 

properties 

y  Following  use  cases  took  more  time  to  implement  than 

Application  to 

other  nodes  and  more  test  cases  were  required  and 
implemented  in  the  testing  process  than  other  nodes: 

the  system 

Sub2  UC  5 ,  Subl  UC  8,  Sub2  UC  3,  Sub2  UC  7 

integration 
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Analysis  Via  Visualisation  (4)  -  Release  2 
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components 
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Approach 

♦♦♦  The  major  problems  involved  in  system  Integration 

□  Difficult  in  modification  and  maintenance 

Compute  the 

>  Difficulty  in  understanding  the  existing  system  and 

consistency 

interfaces 

□  Not  coherent  and  not  unifying  data  structure 

Identify  the 

□  Many  different  application  and  systems  to  supports 

properties 

>  incompatible  system  and/or  system  interfaces 

Application  to 

□  Aging  of  the  systems 

the  system 

□  Social  issues 
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Application  of  the  approach  to 
the  system  integration  (Cont'd) 

♦v*  The  proposed  approach  is  still  applicable 

□  For  integrating  the  systems  with  well-defined  system  models 

>  The  approach  enforces  the  consistency  checking  principles 

>  Network  analysis  approach  can  provide  good  information  about 
which  components  (nodes)  are  vulnerable  and  with  higher 
complex  (higher  values  of  centrality  and/or  centrality  betweens) 

□  For  integrating  a  new  system  to  an  old  system  without  the 
well-developed  models 

>  If  the  old  system  can  be  reverse-engineered 

■  some  models  can  be  obtained  and  can  be  used  for  analysis  as 
discussed  before 

>  If  it  can  not  be  reverse-engineered 

■  the  old  system  has  to  be  understood,  and  architecture  level 
node  connections  will  need  to  be  developed. 
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Conclusion 


♦t4  Conclusion: 

□  MBSE  provides  a  practical  approach  to  develop  complex 
systems 

□  Models  produced  in  the  system  engineering  processes 
have  to  be  evaluated  or  assessed  to  ensure  that  the 
requirements  are  fully  implemented,  and  models  are 
consistent  throughout  the  entire  engineering  process. 

>  The  proposed  approach  is  the  first  step  toward  addressing 
the  issue 

>  More  research  is  required  to  address  other  burning  issues 

□  In  order  to  have  better  understanding  of  the  system, 
models  have  to  be  studied  from  holistic  level 

>  Networks  science  provides  good  tools  for  studying  the 
holistic  view  of  the  system,  the  interconnections,  and  their 
changes/evolutions 


Unclassified 


208 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0734 


18.  Technical  Risk  Analysis  -  Exploiting  the  Power  of 
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11  2. 

Despina  Tramoundanis  ,  Wayne  Power  and  Daniel  Spencer 
1  2 
Weapons  Systems  Division,  DSTO  and  Aerospace  Concepts 


Abstract 

In  his  2003  review  into  Defence  procurement,  Kinnaird  recommended  that  for  new 
acquisitions  Defence  undertake  a  'comprehensive  analysis  of  technology,  cost  and  schedule  risks' 
and  that  'Government  needs  to  loe  assured  that  adequate  scrutiny  is  undertaken  ....by  DSTO  on 
technology  feasibility,  maturity  and  overall  technical  risk'.  As  a  result,  DSTO  performs  Technical 
Risk  Assessments  (TRA)  to  inform  major  acquisition  decisions  during  the  Requirements  phase 
of  the  Capability  Development  process. 

Instructions  for  preparing  the  TRA  are  found  in  the  Technical  Risk  Assessment  Handbook 
(TRAH)17.  These  instructions  provide  useful  guidance  on  the  nature  of  technology  and 
technical  risks  and  means  for  risk  discovery  and  assessment. 

The  current  TRA  development  practice  has  several  shortcomings,  including: 

•  Existing  templates  do  not  necessarily  fit  every  type  of  acquisition  project. 

•  At  the  early  stages  of  capability  definition,  before  a  materiel  solution  has  been 
selected,  system  decomposition  is  not  always  possible. 

•  The  level  of  discipline  and  rigour  applied  to  risk  analysis  is  variable  depending  on  the 
skills  of  individuals. 

•  System  integration  risk  does  not  receive  adequate  coverage. 

•  The  TRA  is  a  stand-alone  document  meaning  that  the  risk  analysis  is  not  necessarily 
integrated  with  the  capability  definition. 

•  It  is  not  easy  to  see  how  risks  in  one  part  of  the  system  impact  risks  in  other  parts  of 
the  system  that  may  be  directly  or  indirectly  coupled. 

To  address  several  of  these  shortcomings,  this  paper  introduces  the  concept  of  Functional  Risk 
Analysis  (FRA)  conducted  within  a  Model  Based  Systems  Engineering  (MBSE)  environment. 
FRA  is  a  rigorous  technique  used  to  explore  potential  effects  of  functional  failures  or 
degradation  that  result  from  insufficient  technical  readiness,  both  within  and  between  parts  of 
a  system  and  across  system  interfaces.  (FRA  is  analogous  to  Functional  Hazard  Analysis,  a 
technique  applied  in  the  aerospace  domain.)  The  underlying  method  of  FRA  uses  an 
Enhanced  Functional  Flow  Block  Diagram  (EFFBD)  representation  of  the  system  functionality 
and  follows  the  following  procedure: 

1.  Perform  the  following  steps  on  each  function  in  turn: 

a.  Define  the  purpose  and  behaviour  of  the  function. 

b.  Consider  the  technologies  inherent  in  the  function  and  the  potential  failure 
modes  that  may  result  based  on  an  understanding  of  the  technology  readiness. 


17  DSTO,  Technical  Risk  Assessment  Handbook,  Version  1.1,  2010 
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e.g.  'complete  loss  of  function',  'degraded  performance',  'incorrect  operation 
(e.g.  high,  low,  fast,  slow  etc 

c.  Represent  functional  failure  modes  within  MBSE  model. 

2.  Simulate  or  interrogate  the  functional  model  to  assess  the  potential  impact  of 
functional  failures  on  downstream  functions  and  guide  detailed  system  analysis. 

3.  Record  in  the  MBSE  model  the  identified  risks  (i.e.  the  potential  effect  in  terms  of 
severity  and  probability  of  occurrence). 

Once  the  physical  system  has  been  designed  or  selected,  the  FRA  procedure  can  be  repeated 
using  the  system  architecture  to  assess  and  explore  the  effects  of  component  failures  or 
degradation  that  result  from  insufficient  system  readiness.  The  results  of  the  FRA  are  recorded 
in  the  MBSE  model  from  which  the  TRA  report  is  auto-generated  via  the  running  of  scripts. 
This  paper  will  use  a  generic  weapon  system  example  to  illustrate  the  FRA  technique. 
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Overview 

•  Brief  background 

•  The  need 

•  What  is  Functional  Risk  Analysis  (FRA)? 

•  FRA  Implementation  in  an  MBSE  environment 

•  An  example 
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Kinnaird  (200B): 


For  new  acquisition  Defence  should  undertake  a 
comprehensive  analysis  of  technology ,  cost 
and  schedule  risks’ 

‘Government  needs  to  be  assured  that  adequate 
scrutiny  is  undertaken  ...by  DSTO  on  technology 
feasibility,  maturity  and  overall  technical  risk’. 
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Technical  Risk  Assessment 


Pre-l st  Pass:  TRI 

lst-Pass  &  2nd  Pass:  TRA 

Technical  Risk  Assessment  Handbook  (TRAH) 

TRA  templates 

Based  on 

■  Technical  Readiness  Levels  (TRLs) 

■  Risk  assessment  matrix 
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Shortcomings 

•  TRA  templates  do  not  fit  every  type  of  acquisition 

•  Work  only  with  materiel  solutions 

•  Quality  depends  on  the  skills  of  individuals 

•  Inadequate  analysis  of: 

■  System  integration  risk 

■  Risk  coupling 

•  TRA  is  a  stand-alone  document 
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The  Need 


A  rigorous  technique  to  explore  the  potential  effects 
of  functional  failures  and  performance  degradation 
that  result  from  insufficient  technical  readiness, 
both  within  and  between  parts  of  a  system  and 
across  system  interfaces 
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What  is  FRA? 


A  rigorous  technique  used  with  an  MBSE 
methodology  to  explore  the  potential  effects  of 
functional  failures  and  performance  degradation 
that  result  from  insufficient  technical  readiness  of  a 
system  and  its  interfaces 


Application  of  Functional  Hazard  Assessment  methods  to  risk  analysis 
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Functional  Hazard  Assessment 

(modified  from  SAE  ARP4761) 
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FRA  Procedure  Overview 


•  Commence  with  a  functional  decomposition  of  the 
capability  system  and  include  the  system  interfaces. 

•  Define  the  purpose  and  behaviour  of  each  system 
function. 

•  Consider  potential  failure  modes  of  each  function  eg 
loss  or  degradation  of  function 

•  Determine  the  effect  of  each  failure  on  system 
function  and  operational  /  mission  outcomes 

•  Identify,  analyse  and  record  the  risks  (impact  and 
likelihood) 
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£  Australian  Government 


Department  of  Defence 

Defence  Science  and 
Technology  Organisation 


Applying  FRA  as  part  of  an 
MBSE  methodology 
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How  FRA  fits  in  with  MBSE 


Utilise  MBSE  capability  model  to  provide  context 

i 


Structured  analysis  framed  on 
functional  and  system  definition 


Likelihood:  MBSE  provides  structure 
to  elicit  and  store  the  likelihood 
information 

Consequence:  (quick  look)  Structure 
analysis  to  determine  flow  on  effects 
and  impact  to  mission  outcomes 
(model  traceability) 

(rigorous)  Perform  discrete 
simulations  of  different  risk  events 


Provide  structure  and  simple  scripting  to 
determine  overall  risk  level 


Figure  3:  Risk  management  process 


1 .  AS/NZS  ISO  31000:2009 
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Required  model  state 


•  Functional  decomposition  defined 

•  Functional  flows  modelled 

•  Information  flows  modelled  and  connected  to 
functions 


\ 

Required  for 
EFFBD 
representation 

_ J 


If  a  materiel  system  does  not  exist: 

■  Perform  risk  analysis  on  available  technologies  to 
perform  functions 

■  Identify  indicative  risk  areas  in  achieving 
functional  and  operational  outcomes  due  to 
technology  maturity  issues 

■  Repeat  FRA  when  the  materiel  system  is  known. 
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Model  elements  and  relationships 
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Information  Flows 


- 1 

R«tjon2 

! 

Component  2 
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FRA  Process 

(Modified  FMEA  Process) 

1 .  Determine  objectives 

■  To  identify,  analyse  and  evaluate  risks  related  to  technical 
readiness 

2.  Identify  starting  points  for  analysis  (mode) 

3.  Identify  upstream  mechanisms  (causes) 

4.  Identify  downstream  effects  (impact  on  system 
performance  and  mission  outcomes) 

5.  Analyse  and  record  overall  risk  (trace  to  affected 
mission  outcomes) 
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3.  Consider  upstream  causes  of  functional  failure 

•  Use  tool  support  to  produce  report  on  “success  path” 

•  Start  from  chosen  function,  consider: 

■  “triggered  by”  items:  Will  always  impact  flow 

■  “inputs”  items:  May  affect  quality  of  flow 

•  For  the  items  collected,  consider  the  other  functions 
they  are  “output  from": 

■  If  multiple  “output  from”:  Redundancies  in  path 

•  Continue  backwards  through  the  success  path 
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Upstream  risk  patterns 


Redundancy  -  decreased  likelihood 
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4.  Consider  downstream  effects  of  functional  failure 

•  Use  tool  support  to  produce  report  on  “success  path” 

•  For  each  function,  consider  the  items  it  “outputs” 

•  For  each  item,  consider: 

■  “triggers” functions:  May  impact  flow,  but  also  need  to 
consider  if  other  functions  are  able  to  output  this  item 

■  “input  to”  functions:  May  affect  quality  of  flow 

•  Continue  forward  through  the  success  path 
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Downstream  risk  patterns 


Critical  path  -  significant  consequence 


Redundancy  -  decreased  consequence 
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Analyse  and  record  resulting  risk 

•  Create  technical  risk  element  in  the  model,  related  to 
the  Function  /  Item  /  Link  analysed 

•  Record  risk  ratings  (likelihood,  consequence)  and 
mitigation  strategies 

•  Output  Technical  Risk  documentation  from  the  model 

•  Risk  can  result  in  a  design  decision  and  derived 
Requirement 
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5.  Analyse  and  record  resulting  risk 


Likelihood  i 

Consequence/Impact 

Minor 

Moderate 

Major 

More  Than 

Likely 

MEDIUM 

HIGH 

HIGH 

Less  Than 

Likely 

LOW 

MEDIUM 

HIGH 

Unlikely 

LOW 

LOW 

MEDIUM 

TRAH  Risk  Likelihood  /  Impact  Matrix 


1 .  Technical  Risk  Assessment  Handbook 
Requirements  Division,  DSTO,  2010 
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Example  -  Ground  Based  Air  Defence 
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Upstream  functional  traceability 

To  guide  the  analyst  in  understanding  the  potential 
influences  on  critical  functions 


What’s  the  likelihood  of  failure? 
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Upstream 


Gjde  to  irt<rc<**  pur* 


Reteve  target  .uUc 


In-tligtt  Urci et  .alia 


Prurade  target  KXtHes 
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Downstream 


1 

I 


I - 1 

=s»l 
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Benefits  of  methodology/  Conculsions 

Issues  with  current  practice 

FRA  Benefit 

TRA  templates  do  not  fit  every  type  of 
acquisition 

Focus  of  risk  analysis  is  on  a  model  of  the  capability 
of  interest,  not  on  a  document  template. 

Documentation  is  derived  from  the  risk  analysis,  not 
the  other  way  around. 

Need  to  assume  a  materiel  solution 

FRA  can  be  applied  to  a  functional  description  of  a 
system  using  knowledge  of  available  technologies 
(pre-2nd  pass)  and  is  repeated  for  physical  systems 
at  2nd  Pass. 

Quality  depends  on  the  skills  of 
individuals 

Provides  a  rigorous  process  to  assist  in  the  analysis 
of  whole  of  system  technical  risk 

Inadequate  analysis  of: 

System  integration  risk 

Risk  coupling 

Process  guides  analyst  through  the  potential 
influence  of  technologies  on  other  systems  and  sub¬ 
systems. 

Focus  is  on  potential  impact  of  integration  risk 

TRA  is  a  stand-alone  document 

Analysis  performed  in  and  risks  recorded  in  the 
same  model  OCD  and  FPS  definitions.  Completely 
traceable:  a  single  source  of  truth. 
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Additional  Benefits  /  conclusions 

Resulting  benefits  from  using  MBSE  for  risk  analysis: 

•  Capture  and  trace  risks  and  issues  to  mission 
objectives 

•  Capture  non  technical  risks/issues  (such  fitness-for- 
purpose) 

•  Can  extend  FRA  process  to  system  assessment 

•  Resulting  derived  requirements  can  be  traceable  back 
to  the  analysis  process 
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19.  Modelling  the  Management  of  Systems  Engineering 

Projects 


Daniel  Spencer  and  Shaun  Wilson 
Aerospace  Concepts 


Abstract 

As  described  in  the  INCOSE  Systems  Engineering  Handbook 18 ,  systems  engineering  is  an 
interdisciplinary,  holistic  approach  to  realise  successful  systems.  It  often  involves  a  combined 
effort  of  a  team  of  professionals  from  different  disciplines  and  backgrounds. 

The  primary  role  of  the  Systems  Engineering  Manager  (SEM)  of  a  complex  project  is  to  ensure 
that  the  technical  conduct  of  the  project  and  the  technical  products  achieve  the  required 
quality.  The  SEM  performs  this  role  by  defining  the  technical  processes,  documentation  and 
output  products  within  the  engineering  lifecycle  of  a  project  through  systems  engineering 
management.  These  aspects  of  a  project  are  not  brought  together  through  any  other  single 
management  process.  Furthermore,  systems  engineering  management  supports  the  other 
business  systems  such  as  project  management,  engineering  management  and  quality 
management. 

Particularly  in  early  concept  development  phases  of  a  project,  it  is  important  for  those 
involved  in  Model-Based  Systems  Engineering  (MBSE)  to  not  lose  sight  of  systems 
engineering  management  as  an  enabler  of  engineering  rigour.  Engineers  can  overlook  systems 
engineering  management  amongst  the  MBSE  methods  and  technical  activities  they  are 
conducting. 

In  his  paper  at  the  2004  INCOSE  International  Symposium19,  Eric  Honour  concludes  that 
systems  engineering  effort  improves  development  quality,  cost  and  schedule  compliance,  and 
that  systems  engineering  management  is  known  to  be  an  important  part  of  the  systems 
engineering  process.  Further  to  this,  improved  quality  of  the  systems  engineering  activity 
increases  these  benefits. 

The  key  document  used  to  guide  all  technical  aspects  of  the  project  is  the  Systems  Engineering 
Management  Plan  (SEMP).  The  SEMP  is  now  often  referred  to  as  a  Systems  Engineering  Plan 
(SEP),  and  defines  systems  engineering  organisation,  process  and  products,  and  also  describes 
speciality  engineering  integration  in  a  project20. 

A  SEMP  is  an  evolving  document  that  captures  a  project's  current  systems  engineering 
strategy  and  its  relationship  with  the  overall  project  management  effort.  The  purpose  of  the 
SEMP  is  to  describe  the  detailed  operational  plan  for  executing  systems  engineering.  It  also 
describes  how  a  project  organisation  will  manage  technical  activities  in  accordance  with 


18  Haskins,  C.,  ed.  2010  Systems  Engineering  Handbook:  A  Guide  for  System  Life  Cycle  Processes  and 
Activities.  Version  3.2.  Revised  by  M.  Krueger,  D.  Walden,  and  R.  D.  Hamelin.  San  Diego:  INCOSE 

19  Honour,  E.,  Reducing  Longterm  System  Cost  by  Expanding  the  Role  of  the  Systems  Engineer ,  INCOSE 
International  Symposium,  France,  June  2004. 

20  IEEE,  IEEE  Standard  for  Application  and  Management  of  the  Systems  Engineering  Process ,  Institute  of 
Electrical  and  Electronics  Engineers  1220-2005,  09  Sept  2005 


UNCLASSIFIED 


231 


UNCLASSIFIED 

DSTO-GD-0734 

partners,  clients  and  contractors.  All  other  engineering  control  documents,  such  as  the  Test 
and  Evaluation  Master  Plan,  Configuration  Management  Plan  and  Risk  Management  Plan,  are 
subordinate  to  the  SEMP  and  must  be  consistent  with  it21.  The  SEMP  should  be  established 
early  in  the  project  and  updated  as  necessary  to  ensure  its  effectiveness. 

This  presentation  will  outline  an  example  of  how  a  model-based  systems  engineering 
approach  can  be  taken  to  represent  the  systems  engineering  management  aspects  of  a  project, 
and  how  the  resulting  engineering  management  model  can  be  interrogated  to  produce  the 
outputs  required  for  a  quality  SEMP.  After  describing  the  underlying  structure  of  the  systems 
engineering  management  model,  an  example  will  demonstrate  its  use,  with  a  focus  on 
activities  taking  place  in  Concept  Engineering  phases  of  a  project. 

This  modelling  of  the  project  from  the  point  of  view  of  the  SEM  provides  the  benefits  inherent 
in  the  application  of  MBSE;  consistency,  traceability,  reuse  and  information  sharing.  Further  to 
the  benefits  inherent  in  the  MBSE  method,  benefits  can  be  gained  by  facilitating  the  interface 
between  the  management  system  model  and  the  various  engineering  models  of  the  project. 

Engineering  Management  plan  has  a  number  of  benefits  that  can  improve  product  cost, 
schedule  and  quality  when  used  appropriately.  By  having  an  approach  tailored  to  the  project, 
and  interfacing  this  in  a  useful  way,  the  likelihood  of  its  use  and  the  benefits  of  this  use 
greatly  increase. 

A  robust,  complete  and  consistent  SEMP  provides  clear  and  unambiguous  guidance  to 
systems  engineers  and  technical  staff,  improves  efficiency  of  the  project  effort  and  likelihood 
of  project  success.  Using  a  model-based  approach  to  systems  engineering  management, 
particularly  in  a  model-based  development  environment  closely  couples  the  systems 
engineering  process  and  product,  allowing  clear  definition  of  responsibilities  and  improved 
ability  for  assurance  that  these  responsibilities  have  been  carried  out. 

Presenter  Biographies 

Daniel  Spencer  works  as  a  systems  engineer  for  Aerospace  Concepts  Pty  Ltd.  He  has  over  a 
decade  of  experience  in  design  and  development  of  systems  solutions  across  a  broad  range  of 
industries,  both  in  Australia  and  the  United  Kingdom.  Dan  holds  a  Bachelor  of  Engineering  in 
Information  Technology  and  Telecommunications  from  the  University  of  Adelaide.  He  has 
been  working  with  Australian  Defence  clients  developing  and  refining  tools  and  methods  for 
a  repeatable  and  comprehensive  MBSE  method,  while  using  this  approach  for  real-world 
capability  definition  and  development  projects. 

Shaun  Wilson  is  the  Chief  Executive  Officer  of  aerospace  and  systems  engineering  house. 
Aerospace  Concepts  Pty  Ltd.  He  is  a  practising  systems  engineer  with  particular  expertise  in 
aerospace  modelling  and  simulation  and  conceptual  design.  His  experience  spans  from 
aerospace  and  defence  to  mining  and  leisure  sports.  Shaun  sits  on  a  range  of  company  boards, 
holds  multiple  degrees,  and  is  a  published  in  several  technical  fields. 


21  NASA,  Systems  Engineering  Handbook ,  Revision  1,  December  2007. 
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Outline 


•  Systems  Engineering  Management 

•  Aims  of  the  Systems  Engineering 
Management  Model 

•  Modelling  of  Systems  Engineering 
Processes  and  Management 

•  The  SEMP  as  Output  from  the  Model 

•  Architecture  of  the  Model 

•  Example 

•  Benefits 
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iCj  Systems  Engineering  Management 

Introduction 

•  NASA  Systems  Engineering  Handbook: 

“Systems  engineering  management  is  a 
technical  function  and  discipline  that 
ensures  that  systems  engineering  and  all 
other  technical  functions  are  properly 

applied.  ” 

•  The  goal  of  the  Management  Process  is 
to  organise  the  technical  effort  in  the 
project  lifecycle 

28  November  201 2  Model-Based  Systems  Engineering  Symposium  2012  3 


(S)  Aims  of  the  Systems  Engineering 

Management  Model 

•  Provide  a  template  of  the  Systems 
Engineering  Processes,  Controls  and  Plans 

•  Implement  this  as  model  of  Project 
Management  aspects 

-  Specifically  concentrating  on  Systems  Engineering 
Management 

-  Linked  through  MBSE  tool  to  the  System  and 
Operational  models 

•  Output  SEMP  from  model 

-  Reduce  effort  and  possibilities  of  inconsistencies 
when  tailoring  a  SEMP 

28  November  201 2  Model-Based  Systems  Engineering  Symposium  2012  4 
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Implementing  Systems  Engineering 


Processes 


Existing 

processes  - 
r  Experience 


t  Stakeholder  Project  « 

Cllent  needs  size  Sp6Clalty 
requirements  disciplines 

/  / 


Selected  Systems 

Engineering 

Standards 


Enterprise-wide 
Systems  Engineering 
Processes 


eg: 

IEEE  Std  1220-2005  “The  way  things  are 
ISO/IEC  15288  clone  around  here” 

•May  include  template 
for  a  SEMP 


Project-specific 
Systems  Engineering 
Management  Plan 
and  subordinate  plans 
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(S)  Modelling  Systems  Engineering 

Processes 

•  A  template  is  made  to  be  modified  for 
implementation 

•  Key  is  linking  of  data  together  in  the  model 
-  a  change  in  one  place  reflects  in  others 

•  Have  an  Enterprise-wide  Systems 
Engineering  Process  Model 

•  Instantiate  this  model  for  each  project, 
refining,  tailoring  and  extending  as  required 

28  November  201 2  Model-Based  Systems  Engineering  Symposium  2012  6 
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C5  Modelling  Systems  Engineering 

Management 

•  The  SE  Management  Model  is: 

-A  representation  of  the  systems  engineering 
processes  and  structure 

-  Built  within  a  software  tool  (we  have  chosen 
Vitech’s  CORE,  with  it’s  Program 
Management  modules) 
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C5  The  SEMP  as  Output  from  the  Model 

A  Systems  Engineering  Management  Plan 
(SEMP)  is  the  key  document  used  to  guide 
all  technical  aspects  of  the  project 

•It  defines  SE  organisation,  process, 
products,  and  speciality  engineering 
integration 

•An  evolving  document  capturing  current 
SE  strategy  and  relationship  with  overall 
Project  Management  effort 

28  November  201 2  Model-Based  Systems  Engineering  Symposium  2012  8 
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DoDAF  2.0  Project  Viewpoints 


•  PV-1 :  Project  Portfolio  Relationships 

-  Represents  an  organisational  perspective  on  the  project 

•  PV-2:  Project  Timelines 

-  Can  be  Gantt  chart  view  of  the  project,  including 
dependencies 

•  PV-3:  Project  to  Capability  Mapping 

-  Maps  project  to  capability,  showing  how  elements  help 
to  achieve  a  capability 

-  Analogous  to  SV-5a  (Operational  Activity  to  System 
Function  Traceability  Matrix) 

•  UPDM  provides  a  standardised  way  for  representing 
these  viewpoints 
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SEMP  Viewpoints  on  the  Model 


♦  Work  Breakdown  Structure 

-  Hierarchy  of  all  work  packages  for  the  project 

-  Systems  Eng  Processes  and  Controls  are  a  part  of  this  WBS 

*  Descriptions  of  each  Systems  Engineering  Process  and  Control 

-  Process  and  Control  descriptions 

-  Activity  models  allowing  Flow-Block  Diagram  outputs 

-  Responsibilities  linking  to  Engineering  Organisations 

•  Implementations  of  the  three  DoDAF  2.0  Project  Viewpoints 

-  PV-1  to  describe  the  Engineering  Organisations,  including: 

•  Engineering  authority  and  delegation  of  responsibility 

•  Defined  relationships  with  subcontractors,  suppliers  etc 

-  PV-2  to  bring  all  work  packages  together  in  an  Engineering  Schedule 

•  via  higher-level  activity  model  for  the  overall  project 

-  PV-3  to  map  Activities  to  Engineering  Deliverables  and  Capabilities 
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Reference  Model  Architecture 


PV-3 

Link  to  System  Model 


Capability 


rprovides"^ 


System 

Component 


Work  Breakdown 
Structure 


Work  Package  _ -accomplished  b/-> 

[ProgramElement] 


PV-2  Engineering  Schedule 


Program 

Activity 


‘indudes' 

Jl. 


^^‘indudes’ 


“decomposed  by' 


Process  Summaries 


Engineering 

Process  /  Control  [—'accomplished  by*-^ 
[ProgramElement] 


Program 

Activity 


‘assigned  to’ 


decomposed  by’ 


l/ 

Organisation 

"\ 

inciudes* 

X. 

PV-1  Engineering  Organisation 

± 


Risk 


Risk  &  Contingency 


‘Inputs’  /  'outputs’ 

— IT" 


Product 


'“decomposed  by* 

Engineering  Deliverables 


Legend 


Class 


—— “ratal  iorship”-^ 


Program  Management  schema 
classes  available  in  the  MBSE  tool. 


Schema  relationships  available 
between  elements  of  those  dasses. 


Interpretation 


Interpretation  of  the  elements  in  the 
context  of  Systems  Engineering 
Management 
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Example  -  Overall  Engineering 

Activity  Model 
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Example  -  Process  Summary 

Activity  Model 


•  Analyse  Stakeholder  Needs  activity 
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■S)  Example  -  Engineering  Schedule 
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The  Alternative 


•  Document-based  approach  to  developing  a 
SEMP 

-  Systems  Engineering  approach  not  linked  to  WBS 
or  master  schedule 

-  Responsibilities  not  linked  to  project  organisation 

-  System  Engineering  tasks  not  linked  to  capability 

•  In  the  alternative  approach,  changes  made  to 
these  aspects  of  the  SEMP  need  to  be  made 
in  multiple  places 
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Benefits  of  the  Modelling  Approach 


•  Common  benefits  of  MBSE  approach: 

-  Consistency 

-  Traceability 

-  Reuse 

-  Information  sharing 

•  Interfacing  models  through  an  MBSE  tool 

-  Between  Management  Model  and  various  engineering 
and  technical  models 

-  Clearly  define  responsibilities 

-  Improve  abilities  for  assurance  on  these  responsibilities 

•  Produce  a  more  robust,  complete  and  consistent 
SEMP 
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(S)  Benefits  of  a  robust  SEMP 

•  Provide  clear,  unambiguous  guidance  to 
technical  staff 

•  Improve  efficiency  of  project  effort 

•  Improve  capability  quality,  cost  and 
schedule 

The  bottom  line 

•  Improve  likelihood  of  project  success 
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Questions? 

Daniel  Spencer 
Shaun  Wilson 

Aerospace  Concepts  Pty  Ltd 


wmy  concepts .  aero 
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20.  Potential  Benefits  Of  Product  Lifecycle  Management 
(PLM)  2.0  Social  Networking  Capabilities  Within  MBSE 

1  2 

Axel  Reichwein  and  Shaunak  Hemant  Shroff 

1KONEKSYS  and  2MEMKO 


Abstract 

The  reuse  of  Web  2.0  concepts  in  the  context  of  product  development  has  been  coined  "PLM 
2.0".  Its  goal  is  to  facilitate  and  enhance  the  collaboration  between  engineers,  end  users  and 
project  managers.  PLM  2.0  provides  a  transparent  communication  platform  for  knowledge 
sharing  and  knowledge  creation  between  communities  which  were  previously  disconnected 
such  as  engineers  and  end  users.  As  a  result,  all  stakeholders  can  take  a  more  active  role 
during  product  development.  Clients  and  end  users  can  for  example  easily  follow  the  design 
evolution  and  verify  that  their  design  intent  is  being  met. 

As  of  now,  PLM  2.0  concepts  have  been  embedded  in  engineering  software  applications  such 
as  CAD  and  PLM  systems  as  well  as  in  Microsoft  Office  documents.  However,  many  products 
are  increasingly  composed  of  software  and  electronics  which  require  other  design 
representations  than  plain  3D  models  and  documents.  For  instance,  a  system  architecture 
description  is  particularly  useful  in  complex  systems  design  to  represent  at  a  high  level  of 
abstraction  the  main  system  components  and  interactions.  Multiple  stakeholders  from 
different  disciplines  as  well  as  the  clients  and  end  users  can  then  better  identify  interface 
issues  and  design  change  impacts. 

The  paper  provides  a  brief  introduction  to  PLM  2.0  concepts  with  respect  to  social 
communication  and  explores  some  of  the  key  features.  It  further  delves  into  usage  scenarios  of 
PLM  2.0  technology  and  explores  the  benefits  of  such  technology  in  a  general  perspective  of 
the  company.  More  specifically,  an  example  of  using  PLM  2.0  in  early  stages  of  Systems 
Engineering  activities  and  usage  across  a  SysML  example  is  explored. 

The  Systems  Modelling  language  (SysML)  is  increasingly  used  in  Model-Based  Systems 
Engineering  (MBSE)  to  define  the  system  architecture,  requirements,  functions,  use  cases  and 
behaviour  and  cross-cutting  dependencies.  This  article  investigates  the  potential  benefits  of 
supporting  PLM  2.0  social  networking  capabilities  within  a  SysML  modelling  environment  in 
order  to  improve:  the  collaboration  between  clients/ end  users  and  system  engineers,  the 
communication  between  system  engineers  and  engineers  from  other  disciplines,  the 
traceability  and  consistency  between  design  representations  at  multiple  abstraction  levels 
including  requirements,  system  architecture,  PLM,  CAD  and  simulation  models. 

Since  the  human  factor  is  critical  in  reaching  PLM  2.0  benefits,  criteria  are  listed  to  enable 
social  computing  to  reach  its  fullest  potential  within  the  systems  engineering  community.  Two 
major  factors  are  critical  for  the  success  of  social  technologies  in  engineering:  company  culture 
and  communicative  engineers.  Without  a  company  culture  facilitating  and  encouraging 
healthy  discussion,  engineers  will  not  use  PLM  2.0.  In  addition,  the  value  of  PLM  2.0  relies  on 
clear  and  qualitative  contributions  from  engineers.  The  communication  skills  of  engineers  will 
therefore  become  more  important  as  social  technologies  are  increasingly  adopted. 
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Overview 

•  Communication  in  Engineering 

•  Overcoming  communication  barriers  through 
social  technologies 

•  Social  technologies  for  MBSE  2.0 

•  Roadblocks  for  MBSE  2.0 

•  Conclusion 
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Examples  of  communication  failures 


•  Companies  that  design  complex,  highly  engineered  products  all  have  their  horror 
stories.  Ford  and  Bridgestone  Firestone  lost  billions  of  dollars  after  their  failure  to 
coordinate  the  vehicle  design  of  the  Ford  Explorer  with  the  design  of  its  tires. 
Similarly,  Airbus's  development  of  the  A380  "superjumbo"  suffered  major  delays 
and  cost  overruns  because  of  late  emerging  incompatibilities  in  the  design  of  the 
electrical  harnesses  of  various  sections  of  the  plane's  fuselage.  These  mistakes 
probably  contributed  to  the  loss  of  Airbus's  CEO  and  to  important  changes  in  the 
management  of  the  A380  program. 

•  What's  striking  about  these  stories  and  many  others  like  them  is  that  in  virtually 

every  case,  the  people  involved  all  agreed,  in  hindsight,  that  they  could  have 
avoided  their  expensive  mistakes  by  making  sure  that  the  different  teams 
responsible  for  developing  the  products'  components  had  communicated  more 
effectively.  Of  course  with  complex  development  projects,  you  can  never  be 
certain  that  you  have  planned  for  every  contingency.  However,  our  experience 
shows  that  in  the  design  phase  of  such  projects,  many  companies  would  benefit 
from  focusing  sharply  on  the  critical  points  of  contact  among  their  various 
component  development  teams  to  ensure  that  everyone  knows  when  and  with 
whom  they  should  be  sharing  information. _ 

For  example  based  on  documentation  such  as  this  slide! 
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Communication  in  Engineering 

•  Importance  of  Communication 

-  Engineering  is  about  making  good  decisions 

-  Engineered  systems  are  becoming  complex 

•  Communication  barriers  : 

-  Ineffectiveness  of  the  current  communication 
channels; 

-  Restrictions  on  expressiveness  imposed  by  notations; 
and 

-  Social  and  organisational  barriers. 
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How  can  social  technologies  break 
communication  barriers? 

•  Taking  advantage  of  social  Web  2.0  -based  technologies 

-  It  becomes  easier  for  everyone  to  connect  with  everyone 

-  Harvesting  collective  intelligence 

-  Making  communication  more  transparent  and  easier 

-  Adding  context  to  the  discussion  thread  (not  just  a  simple  forum) 

♦  Web  2.0  Examples 

-  Amazon  user  reviews 

-  Wikipedia  articles 

-  Facebook 

-  Twitter 


Social  technologies  applied  to  Engineering:  PLM  2.0! 
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PLM  2.0  Example 


6 


UNCLASSIFIED 


247 


DSTO-GD-0734 


UNCLASSIFIED 


(^(  memko  KDNEKSYS 

PLM  2.0 

PLM  (Product  Lifecycle  Management)  is  a  concept/technology 
that  centers  around  product  development  from  conception  to 
completion. 


People 


Technology  Processes/Practices 


memko 


PLM  2.0  Features 


•  Instant  Collaboration  in  real-time 

•  Distribution  of  information  to  right  channels 

•  Adopts  web  services  architecture 

•  Use  of  3D  models  for  communication 

•  Data  Interoperability 

•  On  demand  access  to  data  -  searchability 
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PLM  2.0  Usage  Scenarios 

•  Start  a  discussion  thread  related  to  a  model  feature 

—  Ask  product  developement  questions 
—  Get  help  on  design  issues 

—  Solicit  feedback  from  a  broad  or  narrow  audience 

-  Ask  for  clarification  on  a  specific  feature 
—  Make  suggestions 

-  Propose  fixes 

•  Participate  in  a  discussion 

-  Participate  in  brainstorming  activities 
—  Give  feedback 

—  Share  best  practices 
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PLM  2.0  Benefits 

•  More  transparent  communication 

•  Ensuring  decision  making  and  process 
information  is  readily  communicated 

•  Less  time  spent  in  meetings 

•  Better  understanding  of  the  history  leading  to 
a  decision 

•  Benefits  of  Service  Oriented  Architecture 

PLM  2.0  for  Model-Based  Systems  Engineering? 
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Systems  Engineering  Activities 

Identify  project  context  and  goals 
Identify  stakeholders 

Identify  functions/features/use 
cases/requirements 

Identify  system  components 

Identify  component  interfaces  and 
interactions 

Identify  analysis  to  be  performed 
Identify  variation  points 


All  activities 
require  many 
interactions 
between 
many 

stakeholders 
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Model-Based  Systems  Engineering 

Behavior 


Structure 

|  ibd  [Block]  ElectncCarOomam  [  ElectncCarOomam  ]} 
bdd  [Model}  Data  [  VehicteComponents  ]) 


•block* 

Battery 

•block* 

••ElectricVehicle 

I 

•block* 

Chassis 

•block* 

ElectricMotor 

1 


Requirements 

req  [Model]  Data  [  Requrcmentsp 


OMG 

SYSTEMS 

MODELING 

LANGUAGE 


Parametrics 

par  [Block]  ElectncCarOomam  [  AcrodynamtcOrag  ]} 


•requrement* 

Autonomy 


Id  =  *1’ 

Text  =  "The  vehicke  shall  be 
able  to  drive  long  distances 
without  recharging  batteries' 


(requirement* 
Battery  StateOfC  harge 


ld  =  *2* 

Text  =  "The  battery  state  of 
charge  shall  be  above  80% 
after  the  New  European 
Driving  Cycle" 


:  ElectricVehicle 


frontalArea :  m* 


•constraint* 

:  AerodynamicDrag 
|  {F*  0.5*  rtio  ’  A  •  Cd  *  v*2) 
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Additional  „Social" 

Usage  Scenarios  in  MBSE 


13 
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Additional  „Social" 

Usage  Scenarios  in  MBSE 


Question  the  value  of  a  SysML 
diagram  (e.g.  to  avoid  modeling 
just  for  the  sake  of  modeling) 


Requirements 

req  [Model]  Data  [  Requrcmentsp 


•requirement* 

Autonomy 

•requirement* 

Battery  StateOfC  barge 

id  =  *r 

Text  =  "The  vehicke  shall  be 
able  to  drive  long  distances 
without  recharging  batteries' 

•derweReqt* 

id  =  *2- 

Text  -  The  battery  state  of 
charge  shall  be  above  80% 
after  the  New  European 
Driving  Cyde' 

Request  references  to  further 
documentation  on  a  SysML 
feature  (e.g.  Word  document) 
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a 


Usage  Scenarios  in  MBSE„ 

Behavior 

~*tm  [State  Machine}  BatteryMode  [  BattcryMode  ]) 


Consider  a  snapshot  of  the 
SysML  model  (e.g.  specific 
version)  and  use  it  as  a  basis  for 
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Benefits  of  an  Integrated  Social 
Engineering  Platform 

•  Ideally,  all  engineering  tools  should  support  social 
interactions  through  a  common  collaboration  platform 


•  Discussion  threads  can  have  a  hashtag  like  in  Twitter 


•  Harness  „wisdom  of  the  crowds" 


•  Tool  interoperability 

http://www.voutube.com/watch?feature=plaver  embedded&v=bfpd 

Uf9gsuc 


16 


252 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0734 


(«  memko  KflWEKSVB 

Roadblock  for  „Social"  Engineering: 

#1  Company  Culture 

•  Social  culture  of  discussions  in  engineering 

•  Cost  of  setting  up  and  maintaining 
infrastructure 

•  Resistance  to  adopt  new  technology 

•  Requirement  to  adhere  to  current  process, 
tools,  methods 

•  Fear  of  leaked  Intellectual  Property 
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Roadblock  for  „Social"  Engineering: 

#2  Anti-social  Engineers 

•  Engineers  typically  do  not  have  the  best 
communication  skills 

•  Engineers  from  different  streams  find  it  hard 
to  communicate  with  each  other  and  with 
non  technical  personnel 

•  Engineers  often  fail  to  express  their  point  of 
view 
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Conclusion 

•  Big  potential  for  MBSE 

•  But  current  roadblocks,  (e.g.  company 
culture)  needs  to  be  overcome,  need  a 
paradigm  shift 

•  Current  demands  of  industry  require  a  service 
oriented  approach  (consumer  centric) 

19 
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CONTACT  US 


AXEL  REICHWEIN 
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MEMKO 

axel.reichwein@koneksys.com 
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Manage  consistently  the  R,  F,  L  &  P  product  definition,  tests  and  "simulate" 
your  specification  before  detailed  design 

Requirements,  Functions,  Logical  Components,  Physical  Components  Allocations 
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ualC 

DEFENCE  SYSTEMS  INNOVATION  CENTRE 

Defence  Systems  Innovation  Centre  (DSIC) 

DSIC  has  been  established  as  a  national  centre  to  help 
Defence  and  Industry  to  address  some  of  the  challenges 
associated  with  a  networked  battlespace,  by  drawing 
upon  the  advanced  research  capability  in  Systems  (of 
Systems)  Engineering,  Network  Communications  and 
Information  Management  in  the  University  of  South 
Australia,  University  of  Adelaide  and  the  University  of 
New  South  Wales  and  international  academic  and 
research  organisations.  DSIC  achieves  this  via 
collaborative  research,  training  and  independent 
consulting  and  technical  advice  services.  DSIC  is  globally 
recognised  as  a  national  centre  for  advanced  engineering 
in  complex  defence  systems. 
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Experimentation 

^  DSTO  J 

c  Simulation  ^ 

Hub  ^ 

Modelling  Simulation 

%  / 

DSTO  Simulation  Hub 

Modelling  and  simulation  is  a  key  enabling  technology 
for  Defence,  supporting  a  wide  spectrum  of  functions 
including  capability  development  and  acquisition, 
training  and  mission  rehearsal,  operations,  force  structure 
analysis  and  R&D.  DSTO  is  a  major  developer,  user,  and 
manager  of  modelling  and  simulation  within  Defence. 
DSTO's  Simulation  Hub  (SIMHUB)  coordinates 
modelling  and  simulation  for  multiple  Defence  agencies 
with  the  research  funded  by  the  DSTO  Enabling  Research 
Program. 

tew 

INCOSE 

Inlernalional  Council  on  Systems  Engineering 

International  Council  on  Systems  Engineering 

INCOSE  is  a  not-for-profit  membership  organization 
founded  to  develop  and  disseminate  the  interdisciplinary 
principles  and  practices  that  enable  the  realization  of 
successful  systems.  Its  mission  is  to  share,  promote  and 
advance  the  best  of  systems  engineering  from  across  the 
globe  for  the  benefit  of  humanity  and  the  planet. 

£ 

I  ENGINEERS  1 

5E3 

Systems  Engineering  Society  of  Australia  (SESA) 

SESA  is  a  Technical  Society  of  Engineers  Australia  and  the 
Australian  affiliated  chapter  of  the  International  Council 
on  Systems  Engineering  (INCOSE).  SESA's  mission  is  to 
share,  promote  and  advance  the  best  of  Systems 
Engineering  for  the  benefit  of  Australian  organisations 
and  community. 
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